IRC channel logs
2024-07-10.log
back to list of logs
<elevenkb>How can I build a package programmatically? <elevenkb>I'm using abcdw's arei, so I don't have access to user commands. <elevenkb>Also, I'm writing an emacs package for lean which has unicode symbols. As a result, the package has its own input method which depends on a json file mapping abbrevations to the appropriate unicode symbol. I feel like this json file belongs in its own output that I populate using a cretain build-step that happens after installing the elisp files, idk. <elevenkb>what is the best way of doing this? surely not a separate package for the abbrevations no? <elevenkb>On further thought, I'll just change the `#:include` argument for the 'install phase. the abbreviations file is really a _dependency_ and so it is inapproprate to include it as a separate _output_ (as if the package could somehow work without it). So either I make a separate package or force it to be included, and I'm going for the latter. <z572>RavenJoad: when i fix/update/remove last few package, just fine. <sturm>anyone else getting some occasional issues with windows not coming to the front under Gnome/Wayland? For example, I have an icedove-wayland window behind a terminal, click on icedove but it stays behind <rhuijzer>Hi. I want to submit a small path, therefore I'll need git:send-email, which is an output of the git package. I cant install it. $ guix install git:send-email , $ guix shell git:send-email, declaring the package in guix home are all succeeding, but it seems that the wrong git is still in my $PATH. <rhuijzer>Does somebody know how to fix? I cannot find this problem in the documentation <rhuijzer>Even ~/.guix-profile/bin/git send-email doesnt work after installing git and git:send-email in my guix profile <rhuijzer>Problem exists between chair and computer. It' <eisbaer>Hi, I'm trying to reinstall guix on archlinux but when I do guix-install.sh --uninstall I always get cannot remove read-only filesystem. Tried rm -rf /gnu already. <rhuijzer>It's mounted as read only. Maybe umounting it will help? <apteryx>haha! I tried opening 'inkbox', an ebook reader packaged in guix, and it produces a warning saying my battery level is critical <dariqq>Hi, i am playing around with with an rpm package for guix and am getting selinux errors even with the policy installed <dariqq>errors are on executing /usr/bin/guix, /usr/libexec/guix/guile and doing things in /run/systemd/userdb <dariqq>interestingly on another system (installed with the install script) i dont get any errors with the systemd stuff <apteryx>looks like inkbox is called 'quill' now <dariqq>i get the errors on for guix and guile (as these are normally in the store and thus correctly labeled) <dariqq>but i dont understand the userdb error. Might be something wrong with my user setup? <bdju>anyone else having trouble running upgrades? getting "died unexpectedly" and something about tls on two attempts in a row. but I think I got further so I'll keep trying I guess <bdju>yt-dlp --version still shows 2023.10.07 but guix search showed 2024.05.27 is packaged... <bdju>and x.com video links aren't playing in mpv so I suspect it really is that older version still somehow. not sure what's happening. when I do guix upgrade yt-dlp it says there's nothing to do <bdju>doing guix install yt-dlp@2024.05.27 says the package will be downgraded from git.4392c46. maybe that was the problem, it thought I had a newer one. getting the correct version output after doing that <ayatsfer>hi guix! does anyone edit guile with neovim? any essential plugins to do so? <ayatsfer>I've been using parinfer-rust, but sometimes it reformats the whole file if it doesn't like parts of it <melodylane>does anyone have any idea how I can configure the `xorg-server` package if I'm only using guix as a package manager? Specifically, it's missing input configuration for libinput, so the keyboard/mouse don't work. <melodylane>I'm trying to use guix on top of a bare bones Debian <dariqq>gmm i think my groups are setup correctly. Not sure why the daemon wants to touch userdb <melodylane>Maybe my question's easier if it's more abstract: if I have two packages A and B installed that both have `/etc/path/to/conf.d`, how can I configure them so that when running package A, the `conf.d` directories are merged? <melodylane>one idea is modify the package definition of A to merge the directory from B as a build step, but the issue with that is that B actually depends on A <dariqq>might be because i am using systemd-sysusers to create/mange the buildusers <lfam>I'm taking a look at build failures on core-updates <efraim>clang always goes in native-inputs? Never in regular inputs? <dariqq>creating the users manually did not change anything. I dont know what else could be causing this <lfam>efraim: Regarding where clang should go, it depends on if it gets used at build time or run time <lfam>If it gets used at run time, it should be an input. If only at build time, then native-inputs, so that in cases of cross-compilation, only the "cross" variant of clang would be made available <efraim>right. mesa-opencl maintained a reference to libclc and clang-18 for aarch64 on core-updates, so now I'm rebuilding mesa again to see if regular mesa keeps a reference <lfam>I was mistaken about libetonyek earlier. The test failure is actually in k18ln, a dependency of libetonyek <lfam>Python-gst (GStreamer GObject Introspection overrides for Python) is also failing on core-updates <lfam>I'll make a report after I clean up my ki18n / libetonyek report <efraim>I've added a warning to several packages that they are dependencies of mesa. If everything builds well I'm going to bump them all locally to llvm-18 and then test again before sending the patch(es) to fix mesa on aarch64 <spenc>hi! this is maybe a silly question, but I'm coming from mainly using npm and trying to figure out how things work in the guix world <spenc>1. Just confirming that I have this right- the guix.scm at the root is roughly equivalent to the package.json in that it specifies how to build the package and what it needs but does not specify specific versions for the dependenices. manifest.scm is roughly equivalent to the package-lock.json in that it specifies specific versions, and is only used for development not by any guix install <spenc>2. is there any way to specify valid semver ranges in the guix.scm? it seems a little scary to assume the latest version of a depencency will always work, but then again not many projects are strict with semver anyways <spenc>& 3. if I make a guix version of a github project, is the reccomended approach to post it to guix's mainiling list independently, or get it upstreamed? And if it is upstreamed, should the guix.scm refer to a git pull of the most recent tagged release or to the local files at the current moment <ieure>spenc, 3. You want to contribute the package definition to Guix, not the package's upstream. <ieure>2. There is no way to specify valid semver ranges for any package definition. Guix focuses on reproduceable builds; a build that pulls a different version of something based on when you build it is not reproduceable. <ieure>1. A guix.scm containing a package definition is not really equivalent to package.json; a package manifest is not really equivalent to a lockfile, either. <ieure>Lockfiles exist to solve a problem which Guix doesn't have in the first place. <spenc>for 3 is it worth also adding an upstream version to get an easy `guix shell` ? <spenc>It also seems a little scary that if I make a package I'd be commited to watching the repo and updating the version number every time a release happens <jpoiret>spenc: that'd be ideal but there's no concept of a maintainer in Guix, you don't have to commit <ieure>spenc, That's how software packaging has worked for decades. <jpoiret>well, of a package maintainer I mean <ieure>3. IMO it's not worth upstreaming a Guix package definition. <spenc>gotcha, thanks, havent packaged anything before <spenc>npm style is all in the same repo, so some github action or manual step of the dev is what adds the package, external ppl dont really do it as far as i know <spenc>For 2. im a little confused, my understanding was that when you include a package as an input, guix uses the version included in the version of guix you have running currently, and guix pull updates all the lists <ieure>spenc, This is a complicated subject. <ieure>spenc, Guix packages exist as package definitions (the (package ...) form). Those definitions are bound to variables in some Guile module. <ieure>spenc, In a package's inputs, you refer to the variable which the (package ...) is bound to. It's unambiguous and only refers to the specific version of the package bound to that varible. <ieure>spenc, Concretely, you might have: (define-public python-3.10 (package (name "python") (version "3.10.0"))) and (define-public python-3.12 (package (name "python") (version "3.12.0"))). <ieure>In your package input, you have python-3.10 or python-3.12 in the inputs, depending on what it needs. <ieure>In a manifest, you provide a /textual/ reference to a package and optional version; it's a little DSL. So "python@3.10.0" will end up referencing the same package definition bound to python-3.10, r "python@3.12.0" will reference the def bound to python-3.12, and "python" will be the latest version of all packages named "python". <elevenkb>Hey there everyone, what is the best foreign distro to run guix on? <spenc>so instead of keeping a copy of every major and minor version, its just the important ones and its up to the maintainers to decide which versions are important <spenc>elevenkb, im clearly a n00b, but it works on linux mint fwiw <dlowe>elevenkb: if you get to choose why not run it bare metal <elevenkb>dlowe: I'm trying to set up a build server on Microsoft Azure. <ieure>spenc, If you needed a very old Python version, like, 2.3, that wouldn't work. There are ways around this, which I don't really understand. <craigbro>elevenkb: I use it under debian, but I'm a retrogrough who just wants an emacs <craigbro>I run it, and a nix vm, on debian and ubuntu because there are langauges I want to play with, and ecosystems I want to work in, that are not packages to guix/nix and it's not work I want to do <dlowe>elevenkb: I've seen people install guix into a volume from debian and then boot into the new volume <craigbro>I actually think starting with it on bare metal is a mistep for newbs <craigbro>because you will need to become very familiar with linking, building, config, env and all that for every language runtime/ecosystem you use <dlowe>elevenkb: fwiw I use guix on debian mostly except for my bare-metal guix box <craigbro>like nix, starting with it on a host, and moving things in as you can, and having a fallback makes it way less frustrating, and frankly lets you learn more because you aren't at risk of biting off too much at once <lfam>I use Guix on Debian and it's fine <lfam>I agree with craigbro's analysis of the trade-offs. It depends on how much you want to learn all at once. If you are on another distro, you have a really easy way to ignore Guix if necessary and use the host distro, which has decades of advice and support online <elevenkb>everyone: I run Guix System already on my laptop. I love it tbqh, even with all the jank. <elevenkb>but that's probably because I live in emacs. <craigbro>it's not jank, it's parenthetical flavor <ieure>elevenkb, I was pretty stoked when I saw there was distro-level support for EXWM. <the_tubular>Is there a way to measure guix newcomers? Specially after all that nix drama ? <the_tubular>craigbro probably has a better answer then, I barely heard about it cause I'm not follwinjg Nix dev <craigbro>elevenkb: long story, lack of moderation and mismanagement as it matured and commercial interest came into play, resulted in alienating long-time contributors <spenc>ok just making sure im clear on this- <spenc>guix builds are reproducable, given you're using the same guix channels and version, but are not reproducable with different channels since those have newer packages <spenc>so rather than package.lock pinning package versions, you'd use --export-channels to lock the current channels <craigbro>some spin it as an activist putsch, but that's not accurate beyond redis or tech tuber headlines <elevenkb>oooh, gotcha. thanks for letting me know craigbro. <lfam>Sorry to hear the problems at Nix, I did read about them superficially as an outsider <craigbro>spenc: yah, I think you are trying to accomplish what we use flakes for at previous job. It's possible also to make your own channels, and then do transforms and add packages to get total control. However, one thing I haven't gotten a grip on, is I don't see chevksums for all inputs in package definitions... so not sure if it's just an optional thing or what <ieure>spenc, Close! Adding channels doesn't change the reproduceability of a package build, because the package definition references a specific variable. Adding a channel cannot change what inputs a package uses. <craigbro>social structure and leadership is important part of project, and it's all political -- it's only `not political` for certain people <ieure>spenc, The version of the channel(s) containing the package's inputs *also* don't impact reproduceability, but it *does* impact whether the package builds or not. Reproduceable means you get the same result every time, whether that's a successful build or a failure. <craigbro>I appreciate guix project for that, btw. thanx <lfam>craigbro: All source origins should have checksums. Can you point to an example where it seems to be missing? We could probably clarify the situation <ieure>spenc, And correct that if you want a fully reproduceable build (again, whether a working or broken build), you need to export the channels/their versions which it builds against, and --export-channels is how to do that. <spenc>i'm still a little confused then, if I want to have two different computers generate the same package (either bit-for-bit, or just using the same versions of things) is time-machine the way to do it? <lfam>Time-machine is a very convenient way to do it <the_tubular>But yeah, I'd be curious if there was a noticeable bump to guix userbase after that <ieure>spenc, Yes, `guix time-machine' with the channel state, then build the package definition. <lfam>Every time you use a Guix command, there is implicitly a particular Git revision of guix.git used to provide the actual code. With time-machine, you choose that revision on the command-line, rather than configuring it some other way. So it's handy <craigbro>lfam: looking, it was while looking at examples from the dev to ci section of the cookbook, but was also indicated by some code I saw (daviwil?) that was doing a package transform to change upstream commit of a git source, and I didn't see a checksum update <craigbro>I just went thru all the guile-xyz and they seem to all have them... that and the guile package are the only guix package defs I recall looking at <spenc>gotcha, ok last try hopefully i got it this time :p <spenc>so each guix install has only one possible way to make a package given that all the package names are immutable variables <spenc>but you can configure what guix build you have by specified what channels it should be built using, or alternatively with time-machine to do it easier <craigbro>so perhaps I came to the wrong conclusion <spenc>craigbro, think we had the same missunderstanding: you can add a new channel to specify a specific version if you need to, but by default knowing exactly what version of guix you're running is enough for it to be reproducalbe <spenc>(corect me if im wrong, clearly dont know it well :p) <ieure>spenc, Note that bit-for-bit builds are a related but different topic (deterministic builds). That depends on the specific build tooling, ex. Clojure's compiler produces non-deterministic output. So it's outside the scope of what Guix can do anything about. <craigbro>spenc: I'm talking about checksums on sources <spenc>ieure, makes sense, not really interested in bit for bit anyways, it seems a little extra <craigbro>I mostly want to avoid juniors with deviating dev systems, and auditable and consistent controls on build systems for CI and shipped artifacts <spenc>it seems like (if i understand it right) if you're all using the same channels, which icludes the sources for guix itself, it should be consistent <spenc>and since channels are git repos, the checksums are handled with that <craigbro>lfam: the example I am looking at has a `...` in the sources section, so I may not have seen that and understood that the sha256 expr was elided for brevity <ieure>spenc, I'm not sure what you mean by that. <lfam>craigbro: Ah, it could be that package transformations are "loose" in this way, not sure <ieure>You can get around the source checksum with a computed origin, but it's very uncommon. <craigbro>lfam: then I'll have to validat my conjecture <lfam>Craigbro: Ah yes, the ... is a common elision in our examples <spenc>probably just ompletely wrong, but my understanding was that the git hash its pulling is a hash of the contents <spenc>so nothing can serve a different fake version to you <spenc>which was my assumption of why craigbro wanted sha356s <ieure>Right, yes. Git commit IDs are hashes of the commit contents. <craigbro>yah, but git itself can transform things that end up on disk <ieure>You can also gpg sign Git commits; I sign all mine. <craigbro>what matters is what is in the input derivation... aka git commit IDs are not sufficient to replace a nar hash or whatever hash is done on the input derivation <spenc>for verifying that nobody else commited to the repo but you, solving the 'this is a valid git hash, but is it made by someone i like' problem <spenc>ok think i understand this a lil bit better now, thank you all so much <craigbro>also gpg signed commits are erm... pinky swears <craigbro>at least in the github, or things using github PR process... <craigbro>the check guix does during a guix pull may be different story <nikolar>yeah on github it's very easy to pretend you're someone else <craigbro>the chinese are already in your chips, and the russians are already in your grandma, so stop worrying <nikolar>and if not the chinese and russians then intel and amd <spenc>thats why i started using guix recently actually <craigbro>no offense to chinese or russians intended <spenc>@intel, not russians, windows is requiring tpm now got fed up with that and finally switched to linux <civodul>attila_lendvai: oops, thanks for the heads-up! <civodul>looks like the problem is that the hook installed by ‘guix git authenticate’ doesn’t work when doing ‘git push --tags’ <attila_lendvai>civodul, on another note, i'm trying to compile a vanilla guix and shepherd in my local env, and i get: Exception caught while loading '/gnu/store/4dp340m6waym3zi2j5p3wvy9ja671xw2-shepherd-file-systems.go': #<&compound-exception compos <attila_lendvai>[ 4.473005] irritants: (service)> #<&exception-with-kind-and-args kind: unbound-variable args: (#f "Unbound variable: ~S" (service) #f)>)>. does that ring any bells? <attila_lendvai>my guix repo is on master, and shepherd is on main. this used to work. maybe it's something cached somewhere... <civodul>attila_lendvai: weird; the ‘service’ procedure was added in 0.10.0 <civodul>but maybe it’s another same-named variable somewhere <attila_lendvai>my guix repo is clean and on master. shepherd also clean and on main. <civodul>‘main’ is the same as 0.10.5 right now <civodul>lfam: thanks for the heads-up; looks like none of the critical services we rely on is affected, right? <spenc>just ran make check for the first time and a few tests failed <spenc>make[4]: *** [Makefile:6628: tests/derivations.log] Error 1 <spenc>make[4]: Leaving directory '/home/me/Documents/guix' <spenc>make[3]: *** [Makefile:6610: check-TESTS] Error 2 <spenc>make[3]: Leaving directory '/home/me/Documents/guix' <spenc>make[2]: *** [Makefile:6859: check-am] Error 2 <civodul>could you share what tests/derivations.log reads? <spenc>roger: though looks like that answered my question, didnt know it logged <spenc>its trying to find savannah and its down rn, so ill try again later <attila_lendvai>civodul, should this work? (eval-when (expand load eval) ... (begin (use-modules (shepherd service)) ... (service ...))) i mean, a non-toplevel use-modules should have compile-time effects? (this is what i see in the generated /gnu/store/[hash]-shepherd-file-systems.scm) <attila_lendvai>i mean, it must, because that's what vanilla guix does. people would be screaming if this was broken... <spenc>ok hopefully last question for a bit, getting to the end of the getting started manual, and running into this when I try to run 'make authenticate' <spenc>make: *** No rule to make target 'authenticate'. Stop. <spenc>nope, was looking at the non /devel/ version, <attila_lendvai>FTR, i misread the code i asked about above. the (eval-when ...) is not wrapping the (begin (use-modules ...) ...), i.e. it's a toplevel form. <Deltafire>is there a command to stop the build just before Make is run, so I can work on it? <lfam>Not sure how to interpret those errors <lfam>Deltafire: There's not a command for that, but you can insert a build phase that errors out (that is, makes the build fail), and build the package with '--keep-failed' <lfam>Then you can enter the build directory and work from there <lfam>In the failed build directory, there's a file named 'environment-variables'. If you source that, and do `guix shell -D $foo --pure`, it come pretty close to approximating the build environment <lfam>Assuming that $foo is your package <civodul>attila_lendvai: non-top-level ‘use-modules’ is not supported; it might work in some cases but shouldn’t be relied on <attila_lendvai>civodul, well, this is what gnu/services/shepherd.scm line 307 generates for shepherd configs <attila_lendvai>i just don't understand why would it fail in my setup and work for the entire community... so i suspect that this is probably not the source of the issue i'm seeing here. <civodul>attila_lendvai: it’s actually at the top-level <attila_lendvai>civodul, yeah, i pointed that out above. i misread it. so the (begin (use-modules)) is at the toplevel. so, it is fine then, right? <lfam>Always a good idea to sleep on it <spenc>i was trying to run `git fetch origin keyring:keyring` from within the guix shell -CPW and it kept returning until I stepped out `Could not resolve host: git.savannah.gnu.org` <spenc>i think this also explains my failing tests <spenc>is guix shell prevented from accessing the internet in some way? <lfam>spenc: -C, --container run command within an isolated container <lfam>spenc: -N, --network allow containers to access the network <lfam>I think you have to pass -N <lfam>I think the idea is to simulate the build environment, which also lacks networking