IRC channel logs


back to list of logs

<oriansj>DynastyMic: well the easiest way is to just modify the package definition and just do guix build -f ${package}.scm
<oriansj>and guix package -i ${package}.scm
***stikonas_ is now known as stikonas
<KarlJoad>How should I go about making an Emacs "meta-package"? Meaning a single name/symbol for an Emacs that has additional packages alongside it, like emacs-guix?
<KarlJoad>My guix-mode package is behaving strangely. Is it better to install that one through Guix rather than MELPA and Emacs?
<littleme>RUNPATH validation failed, how some library like report error, it's build by copy-build
<littleme>copy-build-system, how should i fix that? use the patchelf?
<littleme>yes, patchelf --set-rpath $LIBRARY_PATH, fix that
<iyzsong-w>littleme: cool :)
***muradm` is now known as muradm
<muradm>maximed: what i ment is order of (define-public package ...)'s, not the list of packages within (inputs ...)'s like
<muradm>sneek: tell later maximed: what i ment is order of (define-public package ...)'s, not the list of packages within (inputs ...)'s like
<sneek>later, muradm says: maximed: what i ment is order of (define-public package ...)'s, not the list of packages within (inputs ...)'s like
<nckx>'later tell $nick', muradm. Sneek is very particular.
<muradm>nckx: thanks, not enough coffee yet in the early morning
<muradm>sneek: later tell maximed: what i ment is order of (define-public package ...)'s, not the list of packages within (inputs ...)'s like
<sneek>Will do.
<unmatched-paren>muradm: Looks like you were right about upower and seatd. Which is obvious to me now -- it needs to be able to shut down the machine, which is a privileged operation of course...
<unmatched-paren>Although it still seems to be running:
<unmatched-paren>[I] /home/paren
<unmatched-paren>ʃ ps ax | grep upower
<unmatched-paren> 621 ? Ssl 0:00 /gnu/store/mh0yab1kkjs4625q8gmyhbzpfhlcm2ff-upower-0.99.15/libexec/upowerd
<unmatched-paren>anyone know why go's store hash is just eeeeeeeeeee....?
***srvntx- is now known as srvntx
<muradm>unmatched-paren: things that run and do nothing always disturb me.. :)
<unmatched-paren>muradm: i think i'll try adding a greetd-sway-wlgreet default-session-command for greetd :)
<muradm>unmatched-paren: i use gtkgreet, it looks nicer.. will be sending patches with greeters this weekend.. i hope it wont take another 9 months to repo :D
<unmatched-paren>muradm: I like that wlgreet fits in with the general look of sway :) though in the meantime, i'll try gtkgreet
<muradm>unmatched-paren: not clean yet, will look next weekend
<muradm>and used like
<muradm>there was also tui greeter and qtgreet somewhere
<muradm>apart of wlgreet
<unmatched-paren>muradm: i believe Guix 'R Us has a qtgreet package
<unmatched-paren>though no service stuff yet
<unmatched-paren>i think it had your greetd package too, though I just pushed a commit that removed it now that it's upstreamed
<muradm>package is no brainer, but configuration is .. :)
<muradm>unmatched-paren: seatd was there before under gnu//wm.scm, now it is moved to gnu//admin.scm
<muradm>i don't think greetd was there before
<muradm>and i don't see qtgreet
<muradm>ah thats not guix original channel
<unmatched-paren>yeah, it's a channel jgart started and i help with
<unmatched-paren>often it has wip packages that aren't quite `guix`-quality and packages that are stuck on the mailing list waiting to be merged
<unmatched-paren>(greetd, of course, was the latter)
<muradm>unmatched-paren: yes i see, will look at it later, may be will dump some stuff pending to guix there :D
<podiki[m]>unmatched-paren: just by chance? that's not what I see on my guix version or on the CI
***roptat_ is now known as Guest7900
<unmatched-paren>podiki[m]: what do you mean?
<unmatched-paren>greetd el al. were recently merged
<unmatched-paren>into guix main. so i removed them from guixrus
<unmatched-paren>except for qtgreet, which isn't in guix yet
***Guest7900 is now known as roptat
<CyberSoul>Hello Everyone does guix allow non-free javascript through firefox does guix have firefox or it has icecat
<unmatched-paren>CyberSoul: it has icecat, but you can always just temporarily disable librejs if necessary
<unmatched-paren>or permanently i guess, but i don't see why you'd do that
<CyberSoul>discord is the only non free app I am using ATM
<CyberSoul>so might move it to browser
<CyberSoul>okay thanks I'm out :P
<scisssssssors61>hi. does anyone know how to allow ordinary users to run shutdown?
<maximed>sneek: later tell muradm: I meant the order of (define-public package ...) too. The risk of merge conflicts of (define-public ...) is much higher than the risk for the input order.
<sneek>Welcome back maximed, you have 1 message!
<sneek>maximed, muradm says: what i ment is order of (define-public package ...)'s, not the list of packages within (inputs ...)'s like
<sneek>Got it.
<muradm>maximed: thanks, will take that into account later. do you think for #56096 another patch update is needed to reflect that?
<sneek>muradm, you have 1 message!
<sneek>muradm, maximed says: I meant the order of (define-public package ...) too. The risk of merge conflicts of (define-public ...) is much higher than the risk for the input order.
<muradm>sneek: later tell maximed: thanks, will take that into account later. do you think for #56096 another patch update is needed to reflect that?
<dirtcastle>guix is rolling release. will it get updates as much as and as fast as archlinux?
<jpoiret>dirtcastle: to individual packages? definitely not
<jpoiret>guix doesn't have as much maintainers and contributers
<dirtcastle>oh. if the rolling release is slow at updating software that will be a security problem right?
<dirtcastle>jpoiret: true. it's very underrated.
<jpoiret>depends, usually security updates are handled quite fast
<dirtcastle>hmm. that's nice.
<jpoiret>anyone know arun isaac's irc handle?
***fps_ is now known as fps
<efraim>unmatched-paren: go's hash is eeeeeeeeeeeeeeeeeeeeeeeeeeeeee because of the go-build-system, the reference to go is removed by replacing the hash
<patched[m]>Any good way to get which package provides a certain binary executable or library?
<bjc>sneek: later tell muradm: is the only reason seatd mounts cgroups to maintain compatibility with the elogind service? from what i can tell, seatd doesn't use cgroups itself
<efraim>patched[m]: I normally use find
***mark is now known as mjw
<patched[m]>Aah, I did that but picked the default `out` output, but needed to use `lib` to get libstdc++ from gcc :)
<muradm>sneek: later tell bjc: there are other things that depends on cgroups, especially docker, in order to not break others, i decided to maintain the compatibility. and as I point in my comments, i suppose that cgroups should be a dedicated service-type, instead of coming with either elogind or seatd
<sneek>Welcome back muradm, you have 1 message!
<sneek>muradm, bjc says: is the only reason seatd mounts cgroups to maintain compatibility with the elogind service? from what i can tell, seatd doesn't use cgroups itself
<sneek>Will do.
<muradm>if feasible, i could move cgroups to separate service-type may be next weekend
<bjc>i agree that it should be separate. while the current cgroups is useful for the current docker, it's broken for podman and lxd, which need cgroups v2
<bjc>my inclination is to have it be a separate service, then have things that need it depend on that service
<muradm>bjc: then separate and upgrade maybe? or one step at atime?
<bjc>that way we could have a cgroupsv2 mount, as well, for podman and lxd to depend on
<bjc>if docker depends directly on the cgroupsv1 service, i think it could be done at once
<muradm>separation is better of course, looks to be straight forward, will break only me who does not use %desktop-services :)
<muradm>docker does not explicitly depends on it, implicity expects it
<bjc>i'm working around it for now in my system configs, but it'd be nice to be able to add an lxd-service-type in guix directly that'll mount the appropriate thing
<bjc>yeah, same with lxd/podman
<muradm>work to be done: separate cgroups implementation, reflect elogind, reflect docker
<bjc>but the docker-service-type can depend on the cgroupsv1-mount
<muradm>i don't know why they depend at all. issue is that cgroups is managed by systemd. currently mounting cgroups only to satisfy the dependency which you cannot control?
<muradm>bjc: won't v1 and v2 conflict?
<muradm>or is v2 backward compatible?
<muradm>of course may be container manager is doing some stuff for containerized processes, idk
<muradm>bjc: i think some body updated docker already
<muradm>ah no
<muradm>still elogind in requirements
<bjc>muradm: v1 and v2 *do* conflict. that's why i'd like the things that need the specific cgroup mount to depend on them directly. that way i can have lxd require cgroups v2, docker require v1, and as long as i don't try to run both, things will be fine
<bjc>right now, though, seatd/elogind both put in the v1 mount, so lxd and podman don't work without manual intervention
<muradm>i see.. i would suggest if elogind requires cgroups, and if it works with v1 only, it could be not feasible to do at all
<muradm>s/i would sugget/i would suggest to check/
<muradm>since most people use elogind i suppose
<bjc>i'd say it's not as feasible as i might like, but seatd does give an out
<bjc>i can use seatd with lxd and everything would be fine
<bjc>i'd also argue it's more "correct" to have the service depend on the mount it needs, and since the number of things that actually require cgroups is fairly small, i think that's feasible
<muradm>bjc: what i meant by feasible, is that if elogind requires only v1, then working on other things that require v2 could be pointless, as most crowd is using elogind i suppose
<muradm>since in that case, no body would be able to use lxd for instance without breaking their system
<bjc>that's the case right now, unfortunately -- i can't use lxd and elogind at the same time, safely. however, since seatd doesn't directly depend on v1, then i *could* use lxd with seatd
<bjc>it's not perfect, but it's a lot better than not having any options
<bjc>we'd have to document that lxd only works with seatd, of course
<muradm>bjc: first we have to free lxd from elogind :D
<bjc>it doesn't depend on elogind now. lxd is just a package. the only service that exists is one i'm writing
<muradm>(face palm) sorry seatd
<muradm>i ment
<bjc>another option would be to separate out the v1 mount service and just stick it in either %desktop-services or %base-services. then i could at least filter it out in my os config with ‘modify-services’ and insert a v2 mount
<bjc>that'd be basically the same thing we have today, but at least make it easier to swap it out when necessary
<bjc>actually, thinking about this more: separating the mount out and then having elogind depend on it is actually the same thing we have today, just more explicitly
<bjc>nm. that's already what elogind is doing. i don't know what just happened to my brain that made me write that. 🙃
<bjc>i think i had this idea where service-types were more like a shepherd service, where you could require something and have it pulled into the dag, but that's not possible; so only one thing can define the /sys/fs/cgroups mount point. which means, i think, that it'd have to go into %desktop-services (since that's where elogind-service-type is)
<PotentialUser-95>Hello. Could you help me to configure my guix systems input methods? I started studying French recently, but at work and at home I usually use an us keyboard. From time to time I have to enter some french words in the web browser. What is the best way to achieve this?
<patched[m]>I've been trying to get `guix shell --container` to work with gui programs, but they never seem able to launch. E.g., taking the chromium example in the manual:... (full message at
<muradm>/gnu/store/m2wmfwk2m4390dwbnjm6ps5y4c9pchi5-procps-3.3.16/sbin/sysctl: error while loading shared libraries: cannot open shared object file: Cannot allocate memory
<muradm>hmm.. didn't happen again
<luishgh>hi guix, just wanted to share with everyone that what i was looking for was the `program-file' procedure.
<luishgh> it can be used like this to add executables to the store: (program-file "" #~(system (canonicalize-path (string-append (getcwd) "/"))))
<bjc>how is that different from ‘local-file’?
<luishgh>bcj: `local-file' produces files that have "-r--r--r--" permissions
<bjc>right. i think the solution to that problem is to add the ability to set permissions for ‘local-file’ et al
<luishgh>yep, that would be the ideal solution
<bjc>is that harder than it sounds?
<apteryx>rekado: hi! I'm curious; has the networking reconfiguring to make node 129 public facing already been made?
<apteryx>rekado: I'll write a proper email about it, but I ran some benchmarks on the SAN and local disks over the weekend:
<luishgh>bjc: i was looking through the (guix gexp) source code and it seems it would not be exactly trivial
<bjc>doesn't local/plain-file use computed-file?
<jorge[m]>Hello, as I see the performance of my Gui System, Ram, Disc, etc.
<jpoiret>luishgh: anything you add to the store will have the same perms though?
<bjc>jpoiret: ‘computed-file’ can set any permissions, but the w bits are masked off
<jpoiret>oh right, i was under the wrong impression that everything in the store was r-xr-xr-x
<jpoiret>maybe because i've stared too long at /bin/'s
<luishgh>bcj: they actually use `gexp->derivation', but i guess it's basically the same
<luishgh>it seems adding an argument and adding a `chmod' call if it is present to the gexp would solve it
<bjc>also, there already is a ‘program-file’ defined in gexp.scm?
<bjc>and yeah, you can just call (chmod #$output perms)
<luishgh>bjc: yep, that's the function i ended up using
<bjc>ah, ok
<bjc>that explains the syntax you were using above, then
<luishgh>the major problem i can see with adding this option to `local-file' is possibly having to change the <local-file> record, as its construction seems to part of the ABI
<jpoiret>program-file basically renders a gexp to a script in the store
<bjc>i don't *think* there's an issue with changing the abi, since things get recompiled anyway
<jpoiret>it adds the shebang and needed imported modules if there are any
<jpoiret>bjc: if a record changes, you'll need to recompile all of its uses as well manually
<bjc>right, but that's only going to be an issue for people doing development on guix itself, and we get warnings for that
<bjc>if you're using ‘guix pull’ then i don't think it causes problems
<jpoiret>I just do some grep --include '*.go' -l -R . | xargs rm
<bjc>i use ‘make clean’. your way is probably faster
<jpoiret>oh, if you're defining your own records it'll happen
<jpoiret>there's make clean-go also to clean only go files
<bjc>rebuilding the documentation takes forever
<jpoiret>rather, "grep record-that-changed --include '*.go' -l -R . | xargs rm" :p
<jpoiret>as long as you're using macros, you'll encounter these issues
<jpoiret>guile doesn't keep track of which macros were used to compile one compilation unit
<apteryx>we should fix Guile
<apteryx>it's annoying
<jpoiret>it would need a big internal change to the compiling infrastructure
<jpoiret>i'm not even sure what the ideal architecture would be
<jorge[m]>Hello, as I see the performance of my Guix System, Ram, Disc, etc.
<apteryx>jorge[m]: what about it? it's the 2nd time you send this beginning of a story :-)
<jpoiret>i mean, we have a warning for define-record-type* but that's because the abi check is part of the macro itself and is a ugly hack! but for all other macros the risk is there too
<jorge[m]>apteryx: I want to see my RAM's performance.
<patched[m]>$ guix install htop
<apteryx>OK. You could probably use 'sysbench' or another benchmarking tool to do so
<patched[m]>$ htop
<apteryx>patched[m]: this will show usage, not performance such as read/write speed
<apteryx>jorge[m]: try: guix shell sysbench -- sysbench memory run
<apteryx>on my system:
<muradm>bjc: found a draft for separating cgroups
<muradm>bjc: seems to be working in system-tests, but i could not see docker running completely due to missing network within test container
<muradm>s/test container/system test vm/
<muradm>looks simpler than i tought
<dominicm>does 'guix gc' seemingly wipe out packages in current profiles for anyone else? my home/system profiles are listed in 'guix gc --list-roots' but when I reconfigure without changes it has to redownload everything for some reason.
<muradm>bjc: i assume from some issues on elogind that it works with cgroup2
<muradm>bjc: for instance
<muradm>i think your preferred path would be to upgrade elogind on guix to cgroup2 may be... imho..
<muradm>this does not disband the separation concern
<muradm>however, it will remove compatibility issues
<muradm>bjc: and at least my local guix reports cgroup2 supported $ cat /proc/filesystems | grep cgroup
<muradm>nodev cgroup
<muradm>nodev cgroup2
<apteryx>dominicm: probably grafts
<apteryx>perhaps try with --no-grafts to validate that hypothesis
<dominicm>ah, that makes sense
<jpoiret>dominicm: also, grub is not in the closure of your system, because it's only needed to install it
<jpoiret>so guix gc will wipe it, and next time you reconfigure it will redownload it to be able to grub-install
<fps>hmm, is it possible to run guix on a system and leave kernel and bootloader configuration to manual setup by the user?
<jpoiret>rekado: i'm looking at mumi's graphql api, and i think the main query types aren't great, combined with kolam's lack of error-reporting
<fps>i.e. have everything from running init under guix' control (managed by guix system reconfigure) but never touch the kernel or bootloader?
<jpoiret>issue should not be non-nullable, otherwise looking up a non-existent issue returns nothing because kolam errors out while handling the response
<dominicm>jpoiret: yeah grub make sense, but as far as I can tell on reconfigure it's rebuilding a ton of stuff besides my kernel, so the graft theory seems to make sense. I guess guix only checks the store for the original package, not the package after grafting?
<jpoiret>i'd say the package after grafting
<jpoiret>the thing is that you need the original package to create the grafting derivation even
<jpoiret>if only the grafted one is in the store, guix will first need the ungrafted one to generate the grafting derivation, and then realize it doesn't have to do anything
<jpoiret>(from what i understand)
<dominicm>oh ok, was not aware of that, although that makes sense since grafting basically does find and replace on the package contents right
<dominicm>so it doesn't know the result of grafting a package until it's been built
<apteryx>yes, my understanding of grafts is primitive but your understanding of the process makes sense to me
<apteryx>jpoiret: if that's what happens, I wonder how we could improve it so that it doesn't happen; it seems registering gc roots for both the ungrafted + grafted derivations should ensure things don't needlessly gets downloaded again, right?
<trevdev>How's everyone today?
<bjc>muradm: yes, there is an existing cgroups2 mount in /sys/fs/cgroup/unified, but it doesn't work with podman or lxd. i was going to see if i could make them work with the different mount point, but tbh, if i can just use seatd, i'd rather do that instead
<bjc>i haven't looked into using the …/unified mount point at all, so it might be straight-forward, but i have a sinking feeling it isn't
<bjc>v1 is pretty old at this point. i think all major distros have moved to v2
<bjc>that said, there's a value in supporting v1 so as to not break older software. so making them co-exist would be nice. although i'd prefer to have /sys/fs/cgroups be the v2 mount with a separate place for v1, since i think v2 is the expectation now
<muradm>i see that systemd is shipped by default with cgroup2 layout since 2021, needs to check state of elogind, then check elogind configuration, and configure control-gropup-file-system to do cgroup2 by default, imho.. i didn't see anything that would require v1 explicitly.. any example?
<bjc>i don't know of anything that needs v1, no. i used to have scripts for resource management with virtual machines that used it, but that was a while ago, and i don't know how popular they ever were
<bjc>docker will work with v2?
<muradm>bjc: i rember having arch running cgroup2 and i was using docker extensively
<muradm>while ago...
<bjc>i've used docker on arch with v2, but this is a more recent version of docker
<lechner>Hi, is there a trick to getting USB memory sticks to be mounted automatically? I have gvfs. The behavior may be intermittent
<bjc>i can try docker with v2 on guix at some point today and see what happens
<bjc>does elogind itself require v1, by chance?
<muradm>bjc: i suppose from issues i saw that elogind is configurable either at build time and/or run time for cgroup version/hierarchy
<muradm>basically it comes up to see how far elogind behind systemd (i suppose should be close enough), how old elogind in guix, and then properly configure it
<bjc>latest version of systemd is 251, and elogind is 246.10
<bjc>so that's pretty close
<bjc>oh, nm. 246 was two years ago
<bjc>however, 246.10 will work with v2 if you pass the build --cgroup-controller=unified
<unmatched-paren>muradm: sorry for bothering you again; i realized that your /etc/config.scm uses a variable "greetd-sway-gtkgreet-xdg-session", which isn't defined anywhere in "guix", so I was wondering how it was defined (I guess it's in (local-common)?)
<bjc>i noticed that, too. i suspect it relies on a gtkgreet package that is in a private channel, as well, since guix doesn't have it
<unmatched-paren>bjc: oh! yes, you're right. i just removed gtkgreet from guixrus assuming it had been added /o\
<unmatched-paren>I guess i'll be adding that back once i'm done with wlgreet :)
<rekado>apteryx: yes, node 129 is connected to the public switch and AIUI we don’t need to record the MAC address anywhere.
<rekado>so all that’s needed is to remove the .41 IP from node 130 and assign it to node 129.
<rekado>jpoiret: I’m not using the graphql stuff myself, but you’re welcome to propose changes / patches.
<apteryx>rekado: OK! I'll try taking care of that IP reassignement
<trevdev>Have I set myself up for disaster by having a signing subkey that expires? Just getting a personal channel set up has turned into a confusing mess because my key fingerprint and my signing "authorized key" subkey fingerprint are two different things. The subkey will expire next year.
<maximed>trevdex: Guix doesn't use the expiration dates of keys.
<sneek>Welcome back maximed, you have 1 message!
<sneek>maximed, muradm says: thanks, will take that into account later. do you think for #56096 another patch update is needed to reflect that?
<maximed>(because of exactly those reasons)
<maximed>(where ‘those reasons = expiration things’, not subkey things)
<maximed>(I don't know how key fingerprints & subkey fingerprints interact in Guix)
<trevdev>I couldn't get it to pull because I was apparently signing with my subkey, so I had to switch my authorized key to my subkey, and it still won't pull because now the latest commit "isn't signed with an authorized key" regardless of which authorized key actually exists in the current version of the .guix-authorizations file.
<trevdev>I just imagine that if I had to rotate that key it might break everything. Maybe there's no reason to rotate it, maybe I just need to re-up the expirey, either way I'm not sure why I'm still stuck.
<maximed>trevdev: I guess you modified .guix-authorizations in a commit that wasn't signed by a key authorisaed by the _previous_ .guix-authorizations?
<maximed>IIUC, you can rotate from a key FOO to BAR as follows:
<trevdev>No commit was every signed by a different key, ever
<unmatched-paren>seems like rust-gif is broken...?
<maximed>trevdev: but you said ‘so I had to switch my authorized key to my subkey,
<trevdev>I just had entered the wrong stupid fingerprint into the .guix-authorizations. It was always signed by the subkey.
<maximed>It should still be possible to do key rotation though (with some care)
<trevdev>The notion of having to _change_ authorized keys later on is a separate concern/curiosity
<trevdev>It's still telling me commits aren't signed by an authorized key despite the authorized key fingerprint now matching the subkey. I don't know what this thing wants.
<maximed>trevdex: Is this channel anywhere public (so I can take look)?
<maximed>trevdev: Does the public key file in the keyring branch contain both the old and new subkey, and has the keyring branch been pushed?
<maximed>* trevdex -> trevdev
<maximed>trevdev: Also, what key did you use to sign the commit modifying the .guix-authorizations?
<maximed>(it needs to be the old key, because the new key hasn't been authorised yet, unless subkeys are special somehow (I don't know if they are))
<jgibbons[m]>Does the build daemon that serves all users need to be started as root, or could it be started by a `guix-daemon` user?
<trevdev>maximed: I think that I just learned the hard way that the documented authorized fingerprint, the introduction commit and they actual signature on the commit need to all need to look the same at the same point in time. I'm thinking guix pull doesn't care about what's most current in the repo
<trevdev>This is probably a good thing because if a key needs updating later, it can be added and committed (and signed by the new key) at the same time and it won't break backward references
<jgibbons[m]>My best guess is that, since the build daemon uses chrooted environments for buildind and needs to re-mount the read-only store so it can add things to it, it must have permissions to do all that.
<jgibbons[m]>So either the build dameon must run as root, or the sudoers file must give the build user those permissions.
<maximed>jgibbons[m]: The files in /gnu/store/... are (after building) root. So the build daemon needs to be run as root to be able to do the necessary changes
<maximed>the guix-daemon does not make use of sudo.
<jgibbons[m]>So it needs to be run as root to ensure consistent file permissions?
<maximed>jgibbons[m]: It has to be run as root to normalise the file ownership (among other reasons)
<maximed>I'd assume that "guix-daemon" refuses to start when non-root.
<maximed>Though I don't actually know if that's the case.
<jgibbons[m]>I know a guix-daemon starts when testing. I don't remember if tests must be run as root though.
<maximed>jgibbons[m]: right, for testing it's done a bit differently
<jgibbons[m]>Yeah, a different store prefix is used, not /gnu/store
<maximed>Tests don't need root. /gnu/store needs root.
<jgibbons[m]>the details are probably in the test-env script
<jgibbons[m]>Ok. Thanks!
<trevdev>If a channel depends on some channel that's already declared (but not explicitly set as a dependency) will it impact the success of `guix pull` or `buix build`?
<trevdev>For example, I am depending on packages declared in guix upstream. When I load the package files in repl there are no errors, but guix pull fails due to not being able to build dependencies
***mark__ is now known as mjw
<jgibbons[m]>trevdev: Doesn't `guix pull` only update the ~/.config/guix/current profile with the contents of all the declared channels? I wonder what build dependency is missing in your case.
<trevdev>jgibbons[m]: I tried a few changes with my .guix-channel and still ended up getting: cannot build derivation `/gnu/store/<hasn>-profile.drv': 1 dependencies couldn't be built. Yet if I go `guix build -L /path/to/guix-channel" package-name`, the package (which depends on everything in the channel) builds fine.
<maximed>trevdev: Does it say ‘see build log at /....gz’ at some point?
<maximed>trevdev: Also, what's failing: "guix pull" or "guix build ..."?
<jgibbons[m]>trevdev: Usually above the "1 dependencies couldn't be built" message it shows a red error saying that a package failed to build. A build log would be helpful in resolving this.
<trevdev>jgibbons[m]: It would be, if it said more than:
<trevdev>(repl-version 0 1 1)
<trevdev>(exception misc-error (value #f) (value "no code for module ~S") (value ((ruby))) (value #f))
<maximed>trevdev: Does that module exist under the name where Guile would expect it?
<maximed>That is, in a file named ruby.scm
<maximed>and at the top-level of the git repo?
<maximed>Otherwise, Guile won't know where to locate it.
<trevdev>I can load the file in geiser without any such repl errors, but maybe some important context is lost during `guix pull`
<maximed>(though that error message should be rewritten to "module ... does not exist\nhint: this that ..."
<trevdev> Here it is. I'm sure I've missed something stupid.
<trevdev>"No code for module ~S" is enigmatic but I suppose it *must* be referring to the package module.
<trevdev>I have declared no such module ~S
<maximed>trevdev: You are setting (directory "packages") in .guix-channel.
<maximed>So Guile will look for (packages ruby) in "packages/packages/ruby.scm".
<maximed>so I expect drropping the (directory "packages") to resolve the issue.
<trevdev>I thought that if my packages were in /any/ subdirectory, I would have to declare it in the channel. Didn't realize that packages was already implicit
<trevdev>See? I knew it would be something silly
<trevdev>As per I got confused. I'll remove the channel config and try again
<maximed>Guile derives file names from module names. So (foo bar xyz) + directory="packages" -> packages/foo/bar/xyz.scm (so TBC: there's no "packages" prefix magic)
<maximed>Though FWIW error messages could be improved a lot.
<trevdev>I didn't think that guile would think to descend into the directories and discover the modules without some explicit starting point at least.
<trevdev>I think I had assumed that with some other config before and it didn't work in my favor.
<trevdev>But learning is like that sometimes
<trevdev>Yep! That did it :D
<trevdev>Thanks for the help guys
<KarlJoad>How should I go about making an Emacs "meta-package"? Meaning a single name/symbol for an Emacs that has additional packages alongside it, like emacs-guix? Just define another package?
<unmatched-paren>KarlJoad: you should be able to adapt this:
<unmatched-paren>that's how you make a meta-package, you use trivial-build-system with a noop builder, and propagate everything you need
<maximed>KarlJoad: WDYM with metapackage -- emacs-guix is just an Emacs another package, not some meta-package AFACIT.
<maximed>* . -> ?
<unmatched-paren>I think they mean "adding additional packages such as emacs-guix"
<unmatched-paren>(I *think*)
<maximed>in that case, "guix import elpa ...".
<maximed>But that's not about meta-packages, and not an Emacs, and doesn't have additional packages, and isn't like hare-toolchain.
<unmatched-paren>Pretty sure they want to define a package, that when installed will provide an Emacs with their extra plugins loaded
<unmatched-paren>like, (propagated-inputs (list emacs emacs-foo emacs-bar))
<maximed>maybe ‘that has additional packages alongside it, like emacs-guix’ meant: with additional package, those additional packages are packages like emacs-guix?
<unmatched-paren>so when they install that meta-package it'll provide an emacs with the plugins foo and bar
<maximed>whereas I interpreted it as ‘a meta-package, ..., like e.g. the emacs-guix meta package"
<unmatched-paren>maximed: not sure :) i guess we'll just wait until they reply
<unmatched-paren>I think they mean what I think they mean because they mentioned meta-packages like gnome and hare-toolchain
<unmatched-paren>(although they didn't say "like gnome and hare-toolchain", of course...)
<unmatched-paren>how do i get the path to a mixed-text-file in the store?
<maximed>unmatched-paren: start "guix repl"
<maximed>do (use-modules (guix gexp) (guix))
<maximed>and ,run-in-store (lower-object (plain-file "foo" "bar"))
<unmatched-paren>maximed: thanks!
<maximed>(that's for plain-file, but same principle should hold for mixed-text-file)
<KarlJoad>maximed: I want a single symbol to refer to Emacs and some additional packages, like emacs-guix. unmatched-paren was on the nose with what I was aiming for.
<maximed>KarlJoad: if you use manifests, you can define a list: (define emacs-things (list emacs emacs-guix ...))
<unmatched-paren>yeah, a manifest is probably better for this come to think of it
<maximed>and insert it in packages->manifest: (packages->manifest emacs-things minetest hello other-things ...)
<KarlJoad>That's another way. I want to make that symbol available through my channel too, and I am not sure manifests can do that.
<maximed>KarlJoad: What do the users of your channel do?
<maximed>Do they use manifests or "guix install"?
<maximed>Channels are ‘merely’ a bunch of Guile modules that Guix can distribute easily.
<maximed>So you can define anything Guile in Guix channels.
<maximed>Lists, procedures, build systems, packages, whatever.
<KarlJoad>I am the only user of my channel, so I can do anything I wang.
<maximed>Just remember to export the list
<maximed>i.e., add #:export (emacs-list) to the 'define-module'.
<maximed>(other exporting mechanisms exist too)
<KarlJoad>Right now, I use guix-home to manage these. I am avoiding guix-install if possible.
<KarlJoad>So I could just define-module a name for the manifest and export the manifest?
<maximed>You could define a module exporting a manifest.
<maximed>Though then you export a whole manifest, not a list of packages.
<maximed>And 'home-profile-service-type' accepts list of packages, but not manifests.
<maximed>So to me it seems you need to export the bunch of emacs-related packages a list instead of a manifest.
<maximed>* a list -> as a list
<KarlJoad>I am not sure what the difference ends up being if I export a list of packages rather than a manifest.
<maximed>KarlJoad: You are using Guix Home?
<maximed>As far as I can tell, you can give Guix Home a list of packages (with home-profile-service-type), but not a manifest.
<KarlJoad>Ahh... I am not trying to make it a module/service-type. Just a package. I would add it to my list of packages in the home-environment.
<maximed>If you want to add it to the list of packages in home-environment, you need a list of packages to append to that list.
<maximed>You can't (easily) convert a manifest into a list.
<maximed>The same reasons apply to home-profile-service-type as to the package list in home-environment.
<trevdev>Would updating my channels inspire `guix home reconfigure` to go and re-download/re-build non substituted packages that are already present (and in some cases running) on my system?
<trevdev>And by updating I mean adding that unrelated channel you guys helped me write earlier
<KarlJoad>So it seems like the method unmatched-paren recommended to me would be better in this case, because manifests are not handled "nicely" by guix home.
<unmatched-paren>maximed: how do i translate a ,run-in-store (lower-object ...) to actual guile code outside the repl?
<maximed>trevdev: The logic behind downloading substitutes is identical for "guix home reconfigure", "guix system reconfigure" and "guix build" and "guix install"
<maximed>unmatched-paren: I don't remember the exact procedure but search for 'open-connection' and 'call-with-store' (not sure about the name)
<maximed>KarlJoad: I guess my point is, is that you don't need to define a meta package.
<maximed>(with its own description, license, etc.)
<maximed>It suffices to define a list of packages.
<trevdev>maximed: Thanks. still trying to come to grips with how guix decides when things have changed. It's building packages that haven't had an update in months. The significant change is the new channel.
<unmatched-paren>specifically, i'm making a session type for greetd (wlgreet), and i need to be able to put a wlgreet.toml into the store and specify it as --config for wlgreet(1)
<maximed>trevdev: Need context -- do you have a build log (
<maximed>Maybe it's building a thing because a dependency of that thing has been updated.
<unmatched-paren>but greetd sessions aren't services, so i can't use the typical service file machinery
<maximed>trevdev: If your package is already present on your system, it won't be build again.
<unmatched-paren>so i need to be able to build a mixed-text-file containing the config, then use its path inside the program-file #~(begin ...) for wlgreet
<maximed>You might notice a package with the same name and version being built again, but it's a different one.
<trevdev>Welp it's building emacs native comp, from which I am chatting from right now
<maximed>(because some phases were modified, or a dependency was modified, or a snippet removed bundling, etc.)
<maximed>to see whether it's the same thing or something different, look at the /gnu/store/HASH-NAME-VERSION.drv name.
<snor>Hi I¨m trying to write a simple manifest, like
<snor>(use-modules (guix profiles)
<snor>             (gnu packages text-editors))
<snor>(packages->manifest (list tree-sitter))
<snor>but when I try to run guix shell, I get a backtrace ending with
<snor>Throw to key `match-error' with args `("match" "no matching pattern" #<<manifest> entries: (#<<manifest-entry> name: "tree-sitter" version: "0.20.6" output: "out" item: #<package tree-sitter@0.20.6 gnu/packages/text-editors.scm:1169 7fdf305b14d0> dependencies: () search-paths: () parent: #<promise #<procedure 7fdf400dedd8 at
<snor>guix/profiles.scm:380:48 ()>> properties: ()>)>)'.
<snor>It kind of looks like it found the tree-sitter package I was looking for but for some reason it is complaining. Does anyone have a clue?
<maximed>Another possibility is grafts, where the ungrafted variant has been automatically removed (after "guix gc") for not being in use anymore.
<maximed>(see a bug on
<maximed>snor: How are you using "guix shell"?
<maximed>"guix shell -f" or "guix shell -m"?
<snor>maximed running it from same directory as the file, just "guix shell"
<snor>and the file is called guix.scm
<maximed>snor: guix.scm is for an individual package, not a manifest.
<maximed>For manifests, name it manifest.scm.
<snor>Aha thanks! :))
<snor>yassss thanks so much!
<unmatched-paren>use guix.scm when you have a project with a local guix package that builds from the source code :)
<maximed>Also, bad error reporting, should be changed to ‘not a package, hint: use the -m option or a file names manifest.scm for manifests’ or such.
<trevdev>Yeah I see 2 native comp checkouts in /gnu/store - the same git checkout. So I guess a dependency updated 🤷
<unmatched-paren>maximed: so, should i use call-with-store and lower-object here?
<unmatched-paren>not sure whether that would be right in this situation
<maximed>unmatched-paren: lower-object: I think so.
<maximed>call-with-store: I don't know. I don't remember the exact procedure.
<maximed>Try, see if it works, I guess.
<unmatched-paren>maximed: rg tells me that call-with-store might be correct here
<unmatched-paren>anyway, thanks! :D
<unmatched-paren>ah, looks like `with-store`, not `call-with-store`
<unmatched-paren>the former is just a macro around the latter tho
<trevdev>Yeah it looks like Guix is reinstalling way more than one or two deps for some reason here. Somewhere along the way I must have confused it and it's seeing the need to re-establish the package versions/provenance
<nckx>Guix is many things but very hard to confuse.
<nckx>Mornin', Guix.
<trevdev>nckx: It is more likely the inverse, to be fair
<trevdev>(I being confused)
<nckx>Nah, I was (mostly) being silly. Guix is very good at spotting changes to the point of sometimes being ‘too’ good, confusing humans and/or appearing pedantic. :)
<nckx>Since Guix hashes inputs, it's very possible that a long rebuild session results in bit-indentical software to what you already had.
<unmatched-paren>guix system: error: #<procedure greetd-wlgreet-xdg-session-command (session)>: invalid G-expression input
<lilyp>procedures are not inputs
<unmatched-paren>oh, /o\
<maximed>sneek: later tell: unmatched-paren: Oops, I didn't actually look at the paste, no call-with-store + lower-object in that place
<unmatched-paren>maximed: oh :P
<maximed>unmatched-paren: Try (let ((config (make-wlgreet-configuration-file etcetera ...))) ...)
<maximed>the lower-object will automatically be done by the G-exp mechanery (in #$config)
<unmatched-paren>ah cool!
<maximed>(it's not only for mixed-text-file, but more generally it holds for any lowerable object, including computed-file, program-file, local-file, package, file-append, let-system ...)
<unmatched-paren>ohh! I know why i get that error now :)
<unmatched-paren>what does (sanitize) do in a define-record-type* field
<maximed>unmatched-paren: It adds a checker that checks whether the value passed to the field is actually correct.
<maximed>The checker can also choose to turn the value into something else.
<maximed>E.g., the input list sanitiser for <package> turns (list foo bar ...) into `(("foo" ,foo") ("bar" ,bar)).
<maximed>(checks = check by throwing an exception if it looks wrong)
<unmatched-paren>maximed: ah, right. that makes sense.
<unmatched-paren>maximed: i suppose i wouldn't be able to add sway automatically to the user's system packages if they put (default-session-command (greetd-wlgreet-xdg-session-command (greetd-wlgreet-session))) in their greetd configuration?
<unmatched-paren>hmm, unless there's some way to temporarily install packages like (with-packages (sway) (execl #$wlgreet #$wlgreet ...))...
<unmatched-paren>would that be possible somehow?
<unmatched-paren>with file-append maybe?
<unmatched-paren>would (file-append sway "/bin/sway") automatically build sway if necessary?
<bjc>i believe that will build sway, yes, since the package will now be referenced in the closure
<unmatched-paren>nice, thanks
<unmatched-paren>okay, time to reconfigure and test this greeter i guess :)
<bjc>are you using gtkgreet for this?
<bjc>nm, i see wlgreet now~
<unmatched-paren>well, it looks like muradm has already done gtkgreet but haven't submitted it yet
<unmatched-paren>so i'm doing wlgreet :)
<bjc>makes sense to me
<unmatched-paren>i suppose i'd have to convert the #<file-append ...> to a string to perform (apply string-append (cons command command-args))
<unmatched-paren>on it
<unmatched-paren>how would i do that?
<bjc>a lot of the time you can just use string-append in place of file-append
<unmatched-paren>In procedure string-append: Wrong type (expecting string): #<file-append #<package sway@1.6.1 gnu/packages/wm.scm:1561 7f51f4f6ebb0> "/bin/sway">
<bjc>right, it'd be (string-append #$sway …)
<unmatched-paren>so in this case #$command i gues
<unmatched-paren>didn't know ungexp worked outside of a gexp :) I have a lot to learn...
<unmatched-paren>...apparently it doesn't. :(
<bjc>it doesn't no
<bjc>you have to have it wrapped in a gexp
<maximed>unmatched-paren: How about #~(stuff ... (invoke #$(file-append the-sway-package "/bin/the-sway-binary") various arguments))?
<bjc>for the greeter stuff, though, you should be in a context that will accept a gexp
<singpolyma>Usually you can avoid gexp. I don't think it's strictly necessary for anything
<unmatched-paren>bjc: this is what i have so far:
<bjc>i don't know what you mean. you'd need a gexp in order to do anything with a build output
<bjc>since only the gexp will have access to the build-side environment, which is where the output is calculated
<unmatched-paren>singpolyma: do you mean "avoid gexp *in packages*"?
<unmatched-paren>because it's certainly necessary for services, it seems
<unmatched-paren>even in packages i'm sure there's gexp-only stuff...
<unmatched-paren>bjc: obviously this isn't the whole file :)
<maximed>Usually, contexts accepting G-exps also accept S-exps and convert them automatically to a G-exp.
<unmatched-paren>but it's the relevant part
<bjc>right. i'm reading it try and understand it
<singpolyma>unmatched-paren: maybe. I've not seen something that needs gexp yet
<unmatched-paren>oh, i know!
<singpolyma>"do anything with a build output" I've definitely done things to outputs using sexp
<maximed>singpolyma: could you point me to an example?
<unmatched-paren>seems like this might work
<bjc>unmatched-paren: is this for a ‘computed-file’?
<unmatched-paren>bjc: no computed-file in sight
*unmatched-paren not even sure what computed-file is :P
<bjc>but you're writing a config file, right? i'd think that has to be done with ‘computed-file’
<unmatched-paren>does it?
<bjc>computed-file is a file-like computed from a raw gexp
<maximed>There's more than one way to make configuration files.
<unmatched-paren>this is the whole file
<bjc>here's a stub i'm using for lxd:
<maximed>'mixed-text-file' is a simple way to make files, but at the same time it's a bit limited in what it can express (e.g., difficult to do JSON configuration formats), so we also have the more expressive computed-file.
<bjc>oh, right. mixed-text will also be a gexp
<unmatched-paren>i see :) this seems fine for mixed-text-file tho
<bjc>anyway, if you're using mixed-text-file, you're creating a file-like, so you're in something that takes a gexp
<bjc>so! what you can do is just introduce a new gexp context so that you can ungexp inside it
<unmatched-paren>so i changed (string-join (cons command command-args) " ") to command " " (string-join command-args " "), would that work...?
<attila_lendvai>Raspberry Pi 4: i searched the mailing list, but it's not clear to me whether Guix System can be installed on them. maybe only the installer image doesn't work, but from a booted raspbian it can be installed? can anyone clarify please?
<bjc>ie: #~(mixed-text-file … (string-append #$sway …))
<maximed>unmatched-paren: what is 'command' andd 'command-args' here?
<maximed>It's a (file-append etc, right?
<unmatched-paren>maximed: command is a file-append, yes
<unmatched-paren>(file-append sway "/bin/sway") by default
<unmatched-paren>and command-args is a list of arguments for the command
<maximed>lemme try
<unmatched-paren>nil by default
<bjc>it's harmless to add a new gexp wrapper around the (mixed-text-file), since (mixed-text-file) is already being used as a gexp
<unmatched-paren>so, the reconfigure succeeds
<unmatched-paren>is there any way i can perhaps inspect the stuff that's been created for the service in the store?
<bjc>the build will print out the store file path, iirc
<unmatched-paren>aha building /gnu/store/2jpjkkbxl2h1lh6ki069j7pnmx6xgqdv-wlgreet.toml.drv...
<unmatched-paren>but the .drv path isn't usually the same as the output path, is it
<bjc>that's for the derivation. i think it also puts the file out, too
<unmatched-paren>can't see it anywhere
<unmatched-paren>only /gnu/store/mdac4hgncjfsw5dh82a62ivybszp3vfj-system
<unmatched-paren>and /gnu/store/14pdvb1a18kapk2zws1nzppqr1h80ymy-grub.cfg
<bjc>hmm. i know i've been able to extract it from somewhere
<unmatched-paren>ah, the output can be found inside the .drv
<unmatched-paren> looks good :)
<unmatched-paren>except for minor formatting issue in make-wlgreet-config-color
<unmatched-paren>trivially corrected and doesn't affect the file's meaning :)
***wehlutyk[m] is now known as Sbastien[m]
<maximed>can't get a mixed-text-file to compile in a repl
<unmatched-paren>this looks fine too:
<unmatched-paren>(what do you call these lowered scheme scripts?)
<unmatched-paren>(/lowered gexps)
<bjc>no? lower-file doesn't work?
*unmatched-paren rebooting, wish me luck :)
<maximed>If I do ,run-in-store (lower-object (mixed-text-file "foo" "bar")), then I get:
<maximed>$14 = #<derivation /gnu/store/ah3yfw0nvw6jaif56r121sgwjiygmvrk-foo.drv => /gnu/store/raihpcxdz6wmdpyj67bwd4bjk02xq0x3-foo 7f862e53f820>
<maximed>but it didn't actually put anything in the store.
<bjc>right, then you can build the derivation
<maximed>but how do I ask Guix to do that
<bjc>(run-with-store store (build-derivation store the-result-of-lower-object))
<unmatched-paren>gah, forgot to ungexp something i thikn
<bjc>or the with-store monad stuff and (built-derivation)
<unmatched-paren>ah, yeah, extra-env
<maximed>Is not a documented procedure.
<bjc>built-derivation is just the monad-y wrapper around build-derivation
<maximed>I'd assume something from (guix)G-exp... or (guix)The Store Monad could be used for this.
<unmatched-paren>...and forgot to specify extra-env in match.
<bjc>i don't know if any of this stuff is documented in the manual. ‘built-derivation’ doesn't even have its own doc string
<bjc>iirc ‘build-derivation’ does, though
<bjc>sorry, ‘build-derivations’
<bjc>and that is in the manual
<bjc>well… it's *mentioned* in the manual
<unmatched-paren>Hmm. I don't understand why it's doing "unexpected syntax in form ()"
<lechner>Hi, anyone serving files with Samba? Thanks!
<unmatched-paren>"HXproc_run_async: ofl: No such file or directory"
<unmatched-paren>maximed: rebooted to this after adding wlgreet to my config and reconfiguring
<maximed>unmatched-paren: Look at 'extra-env'
<maximed>You are putting a literal () in the for-each in greetd-wlgreet-xdg-session-command
<maximed>instead of (list) or '()
<unmatched-paren>would i need to double-quote the () in (command-args (default ...))?
<nckx>lechner: Just FYI, the follow-up (which I didn't read):
<unmatched-paren>i don't really understand why it's ending up like that
*nckx reads… ‘…which I shall optimistically call ‘slow progress’.’
<maximed>unmatched-paren: I would consider #~'() to be more clear.
<unmatched-paren>thank you! :D
<maximed>Also, I would consider replacing #$extra-env by '#$extra-env to be less fragile.
<maximed>(albeit technically less flexible)
<unmatched-paren>nvi is so horrible to use :/
<unmatched-paren>neovim doesn't like the linux tty, you see
<unmatched-paren>reconfiguring! :D
<maximed>Written my thoughts on lowering in <>.
<unmatched-paren>It's certainly taking its time...
<bjc>maximed: thanks. this could definitely use more documentation
<maximed>TBC, on the Guix front, I'm currently working on other things (which also need lots of docs to be written ...)
<maximed>so don't expect a patch by myself anytime soon.
<bjc>guix needs a lot of docs, in general, but it's nice to have some form of to-do list for them, at least, and this particular one has been a pain point for me (and others) in the past
<unmatched-paren>Seems to be hanging on "bootloader successfully installed"...
<unmatched-paren>I'll roll back, reboot, and try again
<bjc>i had that happen once the other day, too. not sure what happened, but rebooting and running the reconfigure again went ok
<bjc>i think i made a change to sheperd, which may have caused it. that may not explain what happened to you, though
<unmatched-paren>progress: i'm now getting errors from wlgreet itself, not guix :)
<trevdev>What's up with propagated inputs? If it has to be callable from PATH, is that where I put something?
<unmatched-paren>trevdev: yep
<unmatched-paren>or patch the references to it in the package source code (if it's being invoked)
<unmatched-paren>this is generally preferred i think
<nckx>Avoid propagation.
<trevdev>Thanks. The deeper I get into packaging stuff, the more I nuanced I realize it is. My contribution to the ruby packages upstream more or less work because of a typo. I thought `inputs` was better. I am not in charge of these Ruby gems, so if they check the path for dependencies, propagate I must :/
<nckx>Sure. Certain languages/‘ecosystems’ within Guix use propagation heavily, for various reasons, but usually boiling down to ‘it was too hard to avoid so far’. Propagation negates some of the advantages of Guix but it's sometimes a necessary evil.
<unmatched-paren>Which package provides shutdown(1)?
<nckx>El Shep.
<nckx>Generally: ‘the init system’.
<the_tubular>Welp, Today I learned
<nckx>A good day.
<the_tubular>It makes sense, but my brain wouldn't have gotten there I think
<unmatched-paren>nckx: thanks
<nckx>urw :3
<the_tubular>but unmatched-paren, I often use
<the_tubular>There's no section for guix, but you can usually guix search whatever it outputs and figure it out
<nckx>Interesting Web site.
<nckx>Fank u.