<lispmacs[work]>command is `sudo guix system reconfigure ~/Manifests/mithril-system.scm' <civodul>lfam: yeah i think it's one of these (C++) <lispmacs[work]>failure error is `ice-9/boot-9.scm:1669:16: in procedure raise-exception: <civodul>berlin spends (spent?) a lot of time building it <civodul>lispmacs[work]: please use a paste service <lispmacs[work]>Git error: failed to resolve address for git.savannah.gnu.org: Name or service not known' <lfam>Thanks civodul. I'm working on the staging branch and it's one of those "to be built" packages. I'm not sure if it has failed on berlin or just not completed yet <lispmacs[work]>civodul: the error is happening on another computer not connected to the network, hence the question <lfam>If it's at the level of Chromium I'll have to punt. I don't have the resources to build that <lispmacs[work]>civodul: I'll need a few minutes to copy the output to usb drive, etc. <lfam>Is it possible to specifically request the build on berlin, civodul? <lfam>I admit I don't really have a sense of how berlin is operated these days <civodul>lfam: it's operated by wonderful people :-) <civodul>gimme the .drv and we'll get it built! <lfam>I don't have an account civodul <lfam>This is the derivation: /gnu/store/b7vizjk66ynx93rc1dc37l06m8fal668-qtwebkit-5.212.0-alpha4.drv <civodul>if you want, you can add yourself to berlin.scm in maintenance.git <lfam>You need the whole file though, right? <civodul>lfam: build started! apparently things like pulseaudio weren't built yet <lfam>civodul: Yup, a lot of unbuilt stuff <civodul>lispmacs[work]: thanks! not a graceful kind of error handling, indeed :-) <civodul>the downgrade-prevention code wants to look at the Git repo <lfam>civodul: If I find that I need another task done on my behalf, I'll add myself to berlin.scm <civodul>lispmacs[work]: there's --allow-downgrades but (1) it's risky, and (2) i think it doesn't disable the check, just turns it into a warning instead of an error <lispmacs[work]>civodul: but if I have no network connectivity, there is no risk, yes? <civodul>--allow-downgrades does not relate to connectivity though :-) <civodul>the risk i'm referring to is a security risk <apteryx>is anyone else using emacs-bash-completion and observed it not behaving well when inside a guix environment (inside M-x shell in Emacs) ? Here, it often hangs on attempting completion and I have to hit C-g too often. <lispmacs[work]>civodul: so, the scenario is I have a guix computer not connected to the network, and I made a small tweak to the system config that doesn't involve any new packages. Just trying to reconfigure it <civodul>lispmacs[work]: yes, so it's the bug i linked to above that's causing troubles here <civodul>yes, like i wrote, it doesn't disable the downgrade check <lispmacs[work]>okay, well, sounds like there is no workaround for the present. I'll "upvote" that bug when I next get access to my email <civodul>in the meantime, you can copy ~user/.cache/guix/checkout to ~root <lispmacs[work]>does somebody happen to know a trick to make the "top" output readable again? All I see is the first 100 characters of those guix file paths <bqv>i asked before but nobody answered <bqv>Nix has a concept of IFD: "evaluation that requires a build to continue", e.g. a derivation that produces more nix code that is then imported <bqv>does guix have a similar concept? <bqv>i ask because it's discouraged in nixpkgs, which frankly, is just a major pain in the ass <lfam>That does IFD stand for? <bqv>"import-from-derivation" <lfam>It's like code generation for derivations? <bqv>i don't know enough about how guix works to explain it better <bqv>imagine code that runs a shell command to generate more lisp, to create a list of derivations, perhaps <lfam>Guix is different in at least one important way, which is that our code has a concept of "packages", built on top of derivations <cbaines>bqv, why does this cause you pain? or putting it another way, what are you trying to do? ***davidpgil1 is now known as davidpgil
<bqv>honestly, i'm just trying to understand this from a guix point of view. I'm as ever very interested in guix, and more frustrated with nix by the day <bqv>my nix config is rife with IFD, so e.g. I have just written a function to read an INI file into json and further into raw nix code <bqv>just wondering how that sort of thing works in guix <cbaines>bqv, Ok, so why are you reading an INI file and generating nix code, what's that for? <bqv>I can then use that ini data as part of my config to create more derivations <bqv>generative, as lfam said <bqv>not just data injection, but the ini data could affect the number and form of derivations created <cbaines>I think I follow, I guess the alternative with Guix is just using Guile <bqv>so a guix config is written directly in guile, which means you can use any guile library, then? <bqv>i hadn't thought of that <cbaines>At least in my understanding, Guix doesn't have the strict "evaluation" thing that I think Nix has <bqv>that is eminently pleasing. <bqv>i like guix more yet <cbaines>Say you're working with some system configuration, running guix system reconfigure /etc/config.scm starts by Guile evaluating /etc/config.scm <cbaines>That file should evaluate to an <operating-system> record, and then some Guile code within Guix will start working with that, potentially building derivations <cbaines>but during the evaluation of /etc/config.scm, you can do what you want <bqv>ah. but then that i suppose highlights why nix does it the way it does <bqv>by having the requirements be derivations too, everything forms a nice reproducible and hermetic tree, which is also distributable like every other build <bqv>i suppose i see both sides <cbaines>In practice, if you're stepping over the line in to something that's not reproducible, then you should see that, I think it's hard to do by accident <bqv>that's a very fair point <bqv>maybe i ought to experiment with this a bit <cbaines>What kind of derivations are you generating from the INI file data, are these bits of software that you're building? <cbaines>I just gave the example of system configuration, as it's easy to explain where Guile does stuff <bqv>i mean, to satisfy your curiosity, I was working on a module overlay to replace all nixpkgs's systemd usage with some other init system, which in some cases requires reading .service files, so I need to have access to that service data at eval time, which means IFD naturally <bqv>so you could envision me going through the generated nixos /etc/systemd directory, reading the unit files, turning them into nix code, and using that nix code to generate a range of new code and derivations <bqv>another probably easier context to understand this in is nix's pkgs.callCabal2Nix <cbaines>I think this brings the discussion back to lfam's last point, that Guix has higher level abstractions/data types in many places <bqv>which will generate a haskell derivation from a cabal file only, without having to run cabal2nix to generate the nix code <bqv>yeah, i think that's the brunt of it, which means i just have to get my head around that <bqv>perhaps i'll go ahead with my plan to use guix-home-manager on my system <cbaines>One of the first things I tried with Guix was generating packages from PyPI, in maybe a somewhat similar style to how stuff from other package managers is brought in to Nixpkgs <cbaines>I didn't get that far, and I have moved on to more mundane stuff since then <cbaines>like putting data about Guix packages in to databases, and just trying to build packages <bqv>one of the major reasons stuff like that is a pain in nixpkgs is the refusal to use IFD. with IFD, rust packages can all be imported in one fell swoop with almost 0 issues. without IFD, each one has to be manually imported by generating some nix files from the cargo file <cbaines>Even though I was working on generating package definitions from PyPI, I wouldn't want to really see that in Guix <cbaines>even though magically importing thousands of packages leads to impressive stats, I think there's more value in writing good quality package definitions, and having tooling that works with those, rather than trying to glue together other package managers with a narrower focus <bqv>there's much to be said about that kind of generation making building other packages easier, though <bqv>e.g. nyxt for a long time could not make it into nixpkgs because of the lispPackages set being so broken <bqv>fixing lispPackages a bit, and subsequently me creating lisp-overlay, made it possible <bqv>perhaps guix would be better served by learning from nixpkgs's political mistakes, and separating the generated stuff out into a separate repository, though? <bqv>(what nix is now trying to achieve with flakes) <cbaines>I think any generated stuff is best kept at arms length, there's value in having lots of good quality package definitions in Guix <cbaines>I think there's also scope for Guix's importers to be able to generate package definitions on the fly <bqv>ah, true, i forgot about that concept. i really like that <cbaines>What I personally think is most important is not comprimising on the utility that Guix offers by providing a standardised way of building software. <lfam>Something I've considered is that certain "ecosystems" are designed with distros in mind, and some aren't. Go and Rust are in the latter category. *Maybe* packages in those languages can be created automatically without any significant risk of lower quality than if they were written by hand. <cbaines>I sometimes worry about this when I see things in Nixpkgs, and they're defined in peculiar ways, or not actually built in part or in full from source <lfam>Other languages actually depend on the distributor to clean things up — one will notice they don't even issue security updates but expect distributors to patch <lfam>But it seems like Rust software really has no need for human intervention here. The entire deployment methodology is integrated and automated <bqv>i think the security patch thing is fair enough, actually. nixpkgs's job is not to maintain every package, just to have it available. rather than patch stuff themselves, they either remove it until patched, or apply a maintainer-supplied patch retroactively <lfam>Older languages don't have a deployment methodology — hence the invention of "distros <lfam>I think it's important for distros to recognize this and plan around it <lfam>There's a conference talk here... maybe even a book <cbaines>I think there's an aspect of distros that's necessary when you want help working with software in multiple languages. Even Rust has an aspect of this assuming your process doesn't start by assuming you're already got a built Rust compiler <bqv>my worry there is it just leads to the blending of concerns. I'd rather the maintenance was left to some other party, even if not the original author, and that derived version is what's used in nixpkgs/guix. That's what happens quite often for "older" packages in nixpkgs <cbaines>There are cases where a general purpose package manager is of no use, but I only really see that in things like https://mirage.io/ . You probably don't need Guix if you're just using OCaml on a hypervisor. <lfam>Guix is hardly afraid of blending concerns :) <bqv>well, at least one reason it should be, is manpower. spending time fiddling with actual project code means less time improving guix as a whole! <cbaines>bqv, lfam it's been a good discussion, but I need to get some sleep, so goodnight! <bqv>fair enough! goodnight :) <ryanprior>I know a number of people who run OCaml on a hypervisor, and they are interested in Guix. <ryanprior>Because you don't do all your dev work using unikernels <bqv>ocaml hypervisor... what is this? <Gooberpatrol66>Is a question about how to package a program more fit for help-guix or guix-devel? <atw>Gooberpatrol66: I think I'd write to guix-devel ***rekado_ is now known as rekado
<rekado>re on-the-fly importing: I’m already doing this for R. <Aurora_v_kosmose>Does Cuirass have some sort of reporting/status feed other than just its logs? <Aurora_v_kosmose>I was thinking of using buildbot for personal stuff, but it seems like it'd be more effort than setting up a private guix channel & cuirass. ***apteryx_ is now known as apteryx
<bdju>I tried to export a different LC_TIME in my ~/.profile and now after a reboot there are locale warnings everywhere and issues showing japanese text. can anyone help? what have I done wrong? I put `export LC_TIME=en_SE.utf8`. I didn't change the other locale things. they're en_US.utf8` <bdju>I tried adding double quotes around the bit after the = sign and rebooting and that didn't help either. the program whose date changes based on LC_TIME shows the intended one now so it should be working, but other stuff is rejecting it maybe <bdju>I suspect I'm hitting guix-specific issues because things I'm finding online are suggesting something similar to what I already did <bdju>does guix not support en_SE? it seemed to take effect in one program and change the time format, though... <bdju>could the problem be that I have LANG set? I read somewhere that LANG will then set all the other stuff. not sure how I'd change LANG, though. maybe the locale option in my config.scm <bdju>I got `build of /gnu/store/0sman4x4hbjadpml219mw9p1hfzr9cgw-locale-2.29.drv failed` when trying to do that <bdju>en_SE.utf8 doesn't show in my `locale -a` output. is that the problem? how do I get it there? <maav>bdju: do you have glibc-locales installed? If you provided it through guix system configuration it should be on /run/current-system/locale/$glibc-version <bdju>I believe my issue is more specific than you're thinking <bdju>maybe this locale is not part of guix <bdju>I do see many locales at /run/current-system/locale/2.31/ but not en_SE.utf8 <bdju>it's a bit of an odd locale, it's a way to get YMD date and 24 hour time while keeping things in english. but it's not really a real one. like the SE is for Sweden, but I'm not in Sweden <bdju>there should also be en_DK for a similar one but DMY date. I don't see that one in the list either <bdju>although setting either one evoked changes in quaternion, so somehow it may be able to access more locales than my general system <bdju>I don't see glibc-locales in my system or user package lists, but my locales were fine until I tried to override LC_TIME in my user profile, so I don't think it's the usual guix locale problem <bdju>is there a way to add more specific locales to guix? maybe some are disabled by default or something... <maav>i've checked glibc-locales, which provides all the locales from glibc, and it isn't there, so it shouldn't be anything guix-related <maav>nope, en_DK is, but not en_SE <bdju>is there any way to get en_SE on my system or am I screwed? <maav>hmmm, providing it through the system configuration probably ends up calling localedef... but you said that it was failing for 2.29 :( <maav>you always can call localedef to another location and override LOCPATH with that, but YMMV <bdju>could I just send an email to bug-guix requesting it be added a proper way? <bdju>and then I'll just revert to what I used before for now probably <maav>there's already a thread open about glibc-locales, even though it was more oriented towards smaller locale sets... perhaps this could be an use case for the latest patch i sent (and probably I should push it) <abcdw>Getting `error: ungexp: unbound variable`, (guix gexp) is imported, what am I doing wrong? <cbaines>abcdw, when are you getting this error? Is it happening on the store side? <abcdw>cbaines, trying to eval this form: (pretty-print (ungexp (file-append pulseaudio "/etc/pulse/default.pa"))) <abcdw>nope, I have it in a file and do `guix system reconfigure` on it <cbaines>Ok, do you have the (gexp ) bit in there as well? <abcdw>cbaines, gexp works fine, pretty print showd this: #<gexp (file-append pulseaudio "/etc/pulse/default.pa") /home/bob/work/nonrde/ixy.scm:17:14 7fb9fa5cc090> <cbaines>abcdw, what I'm getting at is that ungexp works within a surrounding (gexp ...) <cbaines>where is that, and what are you doing with it? <abcdw>Trying to get the path to pulseaudio's default.pa to concatenate the content of this file with my custom settings for pulseaudio service. <abcdw>(ungexp (file-append pulseaudio "/etc/pulse/default.pa")) the internal form is g-expression already as I understand, probably it's not possible to get the result of gexp during evaluation of my system config file and I have to push it to the later stage. <abcdw>cbaines, added gexp around string-append and it worked <abcdw>at least succesfully recnofigured the system <cbaines>looking at your config, modified-default.pa won't have a newline at the end, which might be something to add <abcdw>btw, is it a proper way to update pulseaudio config? Seems too complicated. Almost impossible without lisp knowledge. <cbaines>raghavgururajan, does ./pre-inst-env guile -c "(use-modules (gcrypt hash))" work? <cbaines>Ok, sounds like you're missing Guile gcrypt <cbaines>Guix, the software, has a dependency on Guile gcrypt, which you seem to be missing <raghavgururajan>That's how I bootstrapped. `guix environment guix --pure --ad-hoc guix` <cbaines>I'm not sure what you mean by "bootstrapped" <cbaines>If you run ./pre-inst-env guix build foo inside the shell created by "guix environment guix", then Guix should have the dependencies it needs to function <raghavgururajan>First I installed guix on trisquel using guix.sh script. Then git cloned guix repo. Then did `guix environment guix --pure --ad-hoc guix` <raghavgururajan>Oh you meant to run ./pre-inst-env inside an env, I only used env for doing `./bootstrap` --> `./configure --localstatedir=/var` --> `make` <cbaines>I'm not quite sure if there's something that captures store paths, but to reliably run Guix from the Git repository, you need to make sure the dependencies are available <abcdw>cbaines, the code I wrote didn't work, when I used a modified pulseaudio service inside operating system configuration :/ <cbaines>abcdw, so the file wasn't modified as you'd expect? <abcdw>cbaines, nope, got an error during evaluation) <abcdw>guix system: error: #<procedure 7f843d316030 at guix/store.scm:1961:2 (store)>: invalid G-expression input <abcdw>I hacked the simple solution with local-file and it works as expected. But would like to implement the solution I tried above. <cbaines>abcdw, so, if you read the docstring for text-file, it'll tell you that the second argument, text, should be a string <cbaines>I think you should be using computed-file instead <abcdw>cbaines, thanks. Sounds very reasonable!) <cbaines>abcdw, that change alone won't probably make everything work though. I'd have a look at examples of computed-file being used in Guix, you'll need to create the output file with the contents you want. <abcdw>cbaines, found few examples with system* call, but it looks hacky to write semi-bash script inside gexp. <cbaines>abcdw, perhaps look at crx->chromium-json, that's quite simple <abcdw>call-with-output-file sounds better, thank you. <cbaines>abcdw, g-expressions are effectively easy ways to write a derivation that runs a Guile script (the g-expression), so you can do what you want, including running other programs <abcdw>cbaines, sure I just tried to find a better way then calling some `cats and echoes` using system* function. call-with-output-file should work. <abcdw>It works, but man... I can't see a basic user to do the same. *abcdw brb in few minutes <rekado>abcdw: pulseaudio-configuration should have a field to append text to the configuration file. We have this for other services as well. <abcdw>rekado, it should, but it doesn't have as far as I see :) <abcdw>alsa has extra-options, but pulse has script-file, which by default is equal to (file-append pulseaudio "/etc/pulse/default.pa") <rekado>yes, that’s what I meant by “should” ;) <leoprikler>While that is a valid configuration, would mixed-text-file not be preferrable in most cases? <leoprikler>Note that you should be able to ".include " (file-append "/etc/pulse/default.pa") from your script file. <abcdw>leoprikler, mixed-text-file looks ok, just didn't get the idea behind from function signature. According to documentation looks like an appropriate tool for the task. *raghavgururajan is a pure idiot <raghavgururajan>I was working on packaging telegram-desktop for 5days. Now I formatted the sd card <aecepoglu[m]>Hey, what's the idiomatic way of sharing guix environment specifications. Is it manifest files? <leoprikler>raghavgururajan: Do you have anything still left over or is everything lost? <aecepoglu[m]>leoprikler: how about things that aren't packages that define a system? environment variables, config files, etc <leoprikler>We're not talking about defining a system here any way, that'd be OS config.scm <aecepoglu[m]>I mean, a development environment is also defined by certain environment variables <aecepoglu[m]>And they correspond to a system in guix and not an environment, is that it? <aecepoglu[m]>I'm simply trying to have a point of entry within a directory to setup an environment within which I can run my text editor or the application I'm developing. I had a sh file in which I was calling `guix environment` but that file won't execute the lines after `guix environment` :) <leoprikler>For instance, I have a guix.scm with the following in one of my projects: <aecepoglu[m]>If I were to make it into a guix package, I'd like those environment variables to exist in the environment specification file that guix executes a program in <leoprikler>exec guix environment --ad-hoc -l $0 -- emacs "$@" <cbaines>aecepoglu[m], you might want to take a look at direnv, I use that lots with Guix <cbaines>you can also do things like eval "$(guix environment ... --search-paths)" to amend the environment of the current script <leoprikler>And the rest is the package list for guix environment <leoprikler>You could also make it a manifest by passing -m instead of -l <aecepoglu[m]>hmm. So `KEY1=value KEY2=value && guix environment --preserve=((KEY1)|(KEY2))` <leoprikler>In some instances, you might also describe your environment variables and config files in terms of packages; those can be added to manifests as well. <leoprikler>export KEY1=value1<newline>export KEY2=value2... <leoprikler>--preserve is only needed if you add --pure, but yeah <aecepoglu[m]>leoprikler: how do I describe an environment variable as a package? <aecepoglu[m]>By the way at any point you can refer me to any manual. I try to find the answer on my own by looking at the docs but stil end up getting stuck <aecepoglu[m]>Isn't ` Display the environment variable definitions that make up the environment.` just a way to list the environment? <leoprikler>I think your talking about --search-paths now, right? <leoprikler>The thing is, only the CLI part of that is actually documented <leoprikler>Or wait, there is actually sparse documentation on it in the package reference <leoprikler>By adding a search path specification here, you can set the values for some environment variables <leoprikler>the thing is if you want to e.g. set SOURCE_DATE_EPOCH, that won't work, because you don't set that to a file ***bkv is now known as bqv
<Guest10890>hi guix! I'm on Guix System and noticed that Racket's package manager, Raco, came with the package. So far I've only installed Racket packages available on Guix, and am meaning to create a raco channel, but is it safe to use raco directly if I plan on working on reproducible Racket builds? I'm new and not coming from NixOS, so these details are still setting in. <cybersyn>Sorry, just realized I didn't sign in -- this is the guest who queried above <cbaines>That sounds like more of a Raco question than a Guix question? <Aurora_v_kosmose>Unless you create a new channel for every package update which affects some racket package or their dependencies, raco wouldn't produce reproducible output. <Aurora_v_kosmose>Well, it could coincidentally still produce identical output if what changed doesn't affect your specific Racket build. But that seems like chancing it to me. Of course work might going that isn't documented which might make my current statement false or outdated. <Guest10890>I just wasn't sure if package managers coming through the package manager were somehow "automatic channels" <Aurora_v_kosmose>As for whether such work is happening, #racket would be more up-to-date than me. <Aurora_v_kosmose>If you pin dependency versions in your project, you would get reproducible builds. <Guest10890>yeah, tbh I dont want anything running on my machine that didn't come through the store <Aurora_v_kosmose>I think it'd be easiest to build something which queries the Catalogs and outputs Guix definitions for the items. <Guest10890>thats a good idea! i'll check with the racket crew and if noone has already implemented something like this i'll get to it <leoprikler>cybersyn: Not really, but you could use raco as the basis for a hypothetical racket-build-system similar to how we have maven-build-system etc <Guest5554>yeah, I was reading about this regarding rust crates and was wondering if thats what would be required. being new to Guix and Guile, how complex of task is this? <cybersyn>sorry I don't know why ERC keeps signing me out of my username <Rovanion>I've tried to make a package specification but when I run `guix package --install-from-file=guix-package.scm` I'm told that "guix package: error: cannot install non-package object: #<unspecified>. The package expression seems to return #<unspecified> when I run it in a Scheme REPL, but thats hardly helpful as I'm trying to figure out what's wrong. Any ideas? <aecepoglu[m]>Rovanion: could you paste the code somewhere and share the link here please? <cbaines>Rovanion, the last expression in the file needs to evaluate to a package <cbaines>Rovanion, define-public evaluates to unspecified, try putting nomacs at the end of the file <aecepoglu[m]>Also, I think the scheme code is indented with spaces :) <Rovanion>That worked. But does define-public not return the symbol it defines? <aecepoglu[m]>define-public exposes to the importing module what it has defined. It's basicaly (expose) and (define) combined <Rovanion>Searched for expose but didn't find anything, chalked it up to my lacking foo. ***logiz is now known as doing
***doing is now known as logiz
<ride>How do I reply to a thread on gnu mailman? <ride>Reply via email seems like I will just be sending an email to the person who made the post. <lfam>ride: This is for a mailing list you're not subscribed to? <ride>Do I just reply to the email? <lfam>Then "reply all" should include the address of the mailing list <lfam>I'm not sure how these things work "under the hood" but it seems to work okay, in general <ride>lfam: Thank you! This is my first time using a mailing list. <lfam>I think that even if the address of the mailing list was missing, you could type it in manually, and the list management software should do the right thing. If not, no big deal <Aurora_v_kosmose>lfam: For most of them, replying to the list address with the thread ID in the email headers is generally enough for things to get where they should. <slogman>ctrl+l fails to clear the screen in fish but works fine in bash. Both are not able to find the 'clear' shell command. Any advice? <maav>slogman: clear command comes from ncurses <apteryx>what's the right incanatation to get warnings about file name clashes at the profile generation time? <apteryx>is it simply a matter of increasing the verbosity level? <Rovanion>A software I'm trying to package needs python3 aliased as python at least during build time, what should I do? <jsoo>Rovanion: use the python-wrapper package as a (native?) input <lfam>apteryx: I think it will let you know if there is a collision <jsoo>i'm working on aarch64 support for ghc and i'm getting somewhere. right now it's complaining about not finding ncurses even when specifying the location of ncurses. the way ghc gets host support for an architecture is by cross-compiling, so my hunch is that the ncurses i need to refer to is the build ncurses. does anyone know how i can use two different target-system dependencies to test my theory? <apteryx>lfam: I think for 'guix environment' at least it didn't <lfam>I have a very foggy distant memory of `guix environment` purposefully not warning about collisions, but that's it <apteryx>guix package has a --allow-collisions so it seems OOTB it should error out on collision <jsoo>here's what i have, but i think the target has to be specified only when sent to the build environment: <jsoo> ("ncurses-build" ,(parameterize ((%current-target-system (string-append (%current-system) "-gnu"))) <lfam>apteryx: Check in (guix scripts environment) — #:allow-collisions? is #t <lfam>I think I remember that when the collision checker was introduced, it broke a lot of use cases for `guix environment` <lfam>For that tool, it's more or less accepted and expected that one intends to clobber an existing environment in a ... less-careful way <jsoo>well, i just put an ncurses in native-inputs and it works! <apteryx>lfam: I'm a bit confused because the collision checker was added rather recently (Jun 14 - 993023a28e52c87647fb78a5aa94a524f42ceb71) but I'm pretty sure I used to see lots of collision warnings -- they were muted in 827c56515e06d21aaa23d60ed05b0c45d1d49901 I think. So it seems the same thing to me, but one is at a lower level (union). <lfam>I'm thinking of several years ago, not the recent work <apteryx>just looked in (guix build union). IIUC unless something is catching and muting all of stderr at a higher level, we should still see messages such as "warning: collision encountered ..." even when using 'guix environment' <apteryx>that may be hidden when verbosity level is 1 (quiet), which is the default for most commands <Rovanion>Does anyone happen to know how to change the first argument given to the build system? I want to change the source directory given to cmake without touching the rest. <lfam>Rovanion: You could pass it with the #:make-flags key in (arguments), IIUC <lfam>Rovanion: For cmake-build-system, you may have to use #:configure-flags. I don't think it uses #:make-flags <Rovanion>Hmm, I think I've managed to append something to the end of the config arguments. <Rovanion>And that seems to have worked even though the first argument is still there, so I could just ignore it and go on. <lfam>Now I am wondering if Meson has a standard flag for setting the build directory <Rovanion>I read cmake has a -S flag for doing the same. <Rovanion>Sorry, that is for the source directory. <lfam>Actually, I meant source directory. But the package I'm working on does not use CMake <ufjvp>I'm trying to add a channel (in the installation image) but get an error when running guix pull: opening file '/gnu/store/b5n...-guile-3.0.2.drv': No such file or directory. Does anybody know how to fix it? <lfam>ufjvp: Does that file exist? <ufjvp>No it doesn't (but a file without the .drv at the end exists) <lfam>Hm... I'm not sure what's going on <Rovanion>What is the left hand for in in the inputs list? For almost all packages I've seen the string exactly matches the symbol. <lfam>ufjvp: It could help if you shared with us the full command you ran and the entire output <lfam>Rovanion: Basically, you're giving a name to the package variable that is referred to in other places (such as any let bindings you do in custom build phases) <Rovanion>Sure, but why? Unlike in a let I'm never using the names myself. Who is? <lfam>I don't know... one of our resident Scheme experts will tell you :) <lfam>That whole interface is going to be overhauled and replaced with G-Expressions