IRC channel logs


back to list of logs

<ham5urg>Ahh, channels can be used for that purpose.
<vagrantc>zimoun: i actually perform the builds on a remote machine and sign commits on a local checkout ... frequently have to rebase it anyways...
<zimoun>vagrantc: thanks. Do you sign commits on several machines?
<KarlJoad>Is anyone putting their system configurations into a channel for CI/substitutes? If so, could you link me to your repo? I am trying to get mine working too.
<vagrantc>zimoun: i cherry-pick and or merge the commits to my trusted machine and review them and sign them there
<tinybronca[m]><cbaines> "it's" <- so according to this web interface, tests for package reproducability are confirmed only between TWO build machines?
<cbaines>tinybronca[m], well, "confirmed" is a bit too strong, since you can't really confirm reproducibility, but the data service will show something as "matching" if it knows about at least two substitutes, and they match, and "not matching" if any of the substitutes it knows about don't match
<cbaines>currently, it's only looking at two build farms (sets of build machines) for substitutes, so it is only comparing one to the other
<cbaines>having additional sources of substitutes might help, but it would be better to do more "stress" testing, like deliberately building with different filesystems, dates, core counts, ...
<vagrantc>in reproducible builds we talked about this sort of as the difference between concepts more-or-less "verification builds" and "quality assurance" builds ... if you want to verify a build you actually want to normalize all reasonable factors that you can ... if you want to put pressure on a package to see where it breaks, you want to vary as much as possible
<vagrantc>both have uses, depends on your goal
<tinybronca[m]><cbaines> "having additional sources of..." <- how would additional sources of substitutes help, that just sounds like setting up a mirror for hosting binaries?
<cbaines>the assumption would be that those additional sources of substitutes would be independent, so building things rather than just mirroring another substitute server
<cbaines>so in terms of reproducibility testing, the more builds you compare, the more likely you are to find reproducibility issues
<vagrantc>some reproducibility issues only come up 1 in 100 tries ... some literally with the phase of the moon
<tinybronca[m]>Oh okay yes sorry "additional sources of substittes" by itself did not indicate they would be building as well, but if so then yes that would be great
<tinybronca[m]>cbaines I am curious you say you cannot confirm reproducability, that sounds pessemistic
<vagrantc>does this look like a reasonable patch? for diffoscope ... not sure if python should be in inputs or native-inputs (or added at all, although without it, it didn't work very well)
<vagrantc>the other option would be to fix upstream, but waiting to hear what the other diffoscope maintainers upstream say
<nckx>vagrantc: inputs… it's not run at build time.
<cbaines>tinybronca[m], I'm speaking very generally, but even so, unless your building some software within some formal framework that is provably reproducible, there's no reason why you might get something different the next time you try that build
<cbaines>even I have run in to odd problems, like software that wouldn't build in the last month of the year
<vagrantc>nckx: you mean the script isn't executed at build time, just replacing a reference to it?
<nckx>Or software with a ‘time bomb’, like a test suite that checks that a certificate hasn't expired (don't do that people).
<nckx>It's trivial to write a package that builds bit-identically on 542 machines… but only on the same day.
<nckx>vagrantc: native-inputs and inputs are separate for cross-compiling. Say you're building on x86 for aarch64. If you write the python in native-inputs to your script, it will embed the file name of the x86 python. When you try to run the script later on aarch64, boom.
<vagrantc>nckx: thanks for the explanation!
<nckx>And tests are only run when not cross-compiling (i.e., inputs arch == native-inputs arch) so they will run fine. If that's the ‘build time’ you're worried about.
<vagrantc>i've had the difference between native-inputs and inputs explained more than once ... maybe this time it'll actually sink in. :)
<nckx>I'd be flattered if so. Thinking ‘what happens when I cross-compile’ is really key (and tends to make it obvious, or as obvious as it can be).
<vagrantc>yeah, that's a helpful hook.
<vagrantc>since i do a bit of cross-compiling now and then (though notably not with guix much)
<nckx>Conversely, thinking ‘oh, they are just quirky Guixsynonyms for $BUILD_DEPS and $RUNTIME_DEPS from my favourite $TRAD_PKG_MANAGER’ is a recipe for subtle pain IME.
<nckx>They often overlap, sure.
*nckx → 😴💤 Good night, Guix.
<vagrantc>oh noes!
<vagrantc>oddly enough, it only works when it's in native-inputs ... wat.
<vagrantc>oh wait, this is some other problem, nevermind
<vagrantc>guix shell --pure diffoscope ... reveals some interesting assumptions
<vagrantc>turns out diffoscope doesn't handle well when "
<vagrantc>"diff" is missing
<KarlJoad>Cuirass is not showing currently building software that are dependencies of packages defined in the specification in the web UI. Is that a limitation of the original Cuirass worker implementation?
<vagrantc>oh wow, diffoscope is pretty borken
<vagrantc>yup, none of the packages in diffoscope's 'embed-tool-references work with the current source code ... switched from 'xyz' to "xyz" at some point
<vagrantc>hah... ever since diffoscope 146
<vagrantc>so, i guess the question is ... do we really need to embed those tool references?
<apteryx>probably, if they were a reasonably useful subset of the zillions of the ones it can use
<vagrantc>yeah, i'm thinking it ought to have "diff" out of the box
<vagrantc>oh, it looks like the readelf match does the wrong thing
<vagrantc>i think
<vagrantc>too many \ escapes
<apteryx>GNUtoo: I've re-added h-client, which I ported to Python 3; although it's as useless as before, as the 'submit' button still doen't work (help welcome!)
<apteryx>we'd have to understand why the request payload doesn't work, which is a bit difficult without a good grasp of what may have changed in the PHP server side, which is hosted at
<mothacehe>hey guix!
<civodul>Hello Guix!
<mothacehe>hola civodul
<munksgaard>Is there a quick way to find the path to the binary built by `guix build -f foo.scm`?
<civodul>howdy mothacehe, how's everything?
<civodul>munksgaard: yes, it's the line that gets printed on standard output
<civodul>so you could even write: output=$(guix build -f foo.scm) ; echo $output
<munksgaard>civodul: I see. In my case I get two lines, I think? /gnu/store/hash-foo and /gnu/store/anotherhash-foo-static
<munksgaard>I think I can probably extract what I need, but it would be useful to be able to get those paths after the fact, I think?
<civodul>munksgaard: ah right, you actually get one line per output (most packages have a single output but this one has two of them)
<civodul>after the fact you can just rerun "guix build -f foo.scm"
<civodul>and you'll instantly get those file names
<munksgaard>I see, thanks :)
<civodul>though keep in mind that they're not protected from garbage collection, unless you actually run "guix install" or similar
<zimoun>sneek later tell vagrantc: thanks for sharing the workflow.
<sneek>Will do.
<mothacehe>civodul: fine, thanks :) one of my clients would really like me to be able to screenshare. jpoiret iirc you managed to get it working on icecat@gnome/wayland with pipewire right?
<jpoiret>had to start pipewire + wireplumber + xdg-desktop-portal + xdg-desktop-portal-wlr manually, then start icecat with `LD_LIBRARY_PATH=$(guix build pipewire)/lib icecat`
<civodul>screen sharing works well with icecat/ungoogled-chromium on Xorg
<jpoiret>lmk if it works for you or not
<mothacehe>jpoiret: teams + ungoogled-chromium crashes when screenshare starts, trying with icecat
<jpoiret>haven't tried chromium myself, sorry. I've heard it's more finnicky wrt pipewire interaction
<mothacehe>and teams refuses to start on icecat :(
<mothacehe>i'll maybe find some motivation to investigate the chromium failure, thanks for sharing anyway :)
<jpoiret>i think you need to enable a config flag to get pipewire support in chromium
<jpoiret>apparently chrome://flags/#enable-webrtc-pipewire-capturer
<mothacehe>oh! i doesn't crash anymore!
<mothacehe>but there's an error now
<mothacehe>No such interface “org.freedesktop.portal.ScreenCast” on object at path /org/freedesktop/portal/desktop
<jpoiret>did xdg-desktop-portal-wlr and xdg-desktop-portal launch properly?
<jpoiret>you might need to killall xdg-desktop-portal{,-wlr} first
<jpoiret>you're using gnome not wlroots
<jpoiret>so you need xdg-desktop-portal-gtk instead
<mothacehe>i removed xdg-desktop-portal{,-wlr} killed the one running, installed xdg-desktop-portal-gtk but xdg-desktop-portal-1.10.1/libexec/xdg-desktop-portal is still started
<munksgaard>I can't get `guix shell --container` to find my ssl certificates. I'm using `guix shell wget --container --network --expose=/etc/ssl/certs`, but if I try to `wget` I'm told that is not trusted. What gives?
<munksgaard>Huh, turns out /etc/ssl/certs was a symlink to another file that I also needed to expose.
<jpoiret>mothacehe: xdg-desktop-portal gets autostarted by dbus too
<jpoiret>but iirc it should be ok as long as you start xdg-desktop-portal-gtk
<jpoiret>can't guarantee anything thoug
<nckx>Mornin', Guix.
<civodul>moin nckx
<nckx>‘guix search’ highlighting is a nice new touch.
<nckx>(It's new… right?)
*nckx self-gaslights.
<civodul>it's recent!
<avalenn>I thought about several people here while reading this :
<civodul>avalenn: hey! yeah i saw it earlier today
<ham5urg_>I tried to run the gnu-hurd.qcow2 image with settings like but it breaks with 'hd0s1 not found'. I use virtio, which hd-driver should I use instead?
***IHateSpecing is now known as IForgiveSpecing
<ham5urg_>I got it run with IDE.
<ham5urg_>But what are the login credentials?
***oliver_ is now known as olnw
<civodul>hmm littlebo1eep has networking problems
<apteryx>sneek: later tell mothacehe yeah teams screensharing doesn't work with ungoogled-chromium, because some custom extension gets disabled (it would potentially be a privacy concern), which Teams expect to be available for Chromium. Ironically screensharing "works" in Icecat (albeit badly, and has a tendency to crash).
<sneek>Got it.
<ham5urg_>How to 'guix pull -l' for system wide packages?
***mark is now known as Guest4412
<ardon>Hi Guix, is there a way to allow downgrades on a `guix deploy'? I squashed some commits in my personal channel and now I can't deploy them to a remote server.
<civodul>ardon: hi! yes, there's an 'allow-downgrades?' field in 'machine-ssh-configuration':
<fps>hi, what's the status of guix on a raspberry pi 4b?
<civodul>fps: hi! that's an aarch64 machine, so Guix should work; however, substitute availability is likely low compared to x86_64
<civodul>since 1.3.0, 2 committers reviewed more than half of the non-committer patches
<ham5urg_>Here it is stated that 'guix pull' will act upon '/etc/guix/channels.scm'. Is this similar to a standard-distros 'apt dist-upgrade'? I know there is more inside the user-profiles...
<ardon>Thank you civodul! I completely forgot about that
*civodul emails guix-devel about patch review and all
<civodul>ham5urg_: "guix pull" is more like "apt-get update"
<civodul>whereas "guix system reconfigure" is more like "apt-get dist-upgrade"
<civodul>we should add a "Guix for Debian Refugees" section in the cookbook :-)
<ham5urg_>civodul, thanks for info.
<ham5urg_>I did a 'guix pull --roll-back'. Now I try a 'guix package --list-generations' but get an error like '/root/.config/guix/current/bin/guix' is mssing. What am I missing?
<civodul>ham5urg_: looks you rolled back to generation zero, where ~root/.config/guix/ is empty
<civodul>you can restore it with: /run/current-system/profile/bin/guix pull --switch-generations=1
<ham5urg_>civodul, this reinstalled a package which I installed prior and which was the purpose of rolling back to zero.
<ham5urg_>But now I can remove it, without rolling back to zero.
<apteryx>dominicm: uh uh: Opening nnimap server on gmail...failed: NO (AUTHENTICATIONFAILED) Invalid credentials (Failure)
***Guest4412 is now known as mjw
<apteryx>dominicm: OK, had to enable two factor auth and create an app password; it's working again
<fnstudio>hello! i'm wondering if there's any up-to-date recommended way to install guix on a vps
<fnstudio>would it be possible to create some kind of guix image locally and, when the hosting provider supports this, upload it and spin a machine off of that image?
<fnstudio>i see at least a couple of tutorials online where you create a secondary partition, you install guix there and then reboot into it
<fnstudio>but i was wondering if there were any more recent alternative, a shortcut where you just upload an image
<ardon>fnstudio: I've recently done this with Vultr. You just run a `guix system image' locally, then upload the ISO somewhere public (I used and then upload the URL to the ISO section of your instance dashboard. It's quite trivial
<fnstudio>ardon: hey this is amazing! thanks, i'll try and do the same, ty v much
<ardon>fnstudio: No probs! Good luck 🙂
<tribals>Recently I'm experiencing problems building some java packages. Here is the build log:
<tribals>I've no idea why these packages fails to build. Any ideas?
<julia-l>currently trying to package a new font, and just really not sure what the 'font-build-system' actually does
<julia-l>anybody got pointers for where I should look for docs, or a quick explanation?
<rekado>julia-l: the best way to understand the build systems is to look at the code
<rekado>julia-l: there’s generally no separate documentation for build systems
<rekado>when you visit guix/build/font-build-system.scm you’ll see that it only consists of two phases: unpack and install.
<julia-l>oh I was looking in the wrong file lol
<julia-l>guix/build-system/font.scm is a lot less aproachable
<unmatched-paren>actually, what is the difference between build/*-build-system and build-system/*? what's the logic behind this organization?
<unmatched-paren>i know that build/* is a bit lower-level (afaics) but why couldn't they just be the same file?
<rekado>everything in build happens on the “build side”
<rekado>whereas all the other stuff happens on the “host side”
<julia-l>ah that makes sense :)
<unmatched-paren>ok, that makes sense now, thanks rekado :)
<Guest5>Hi everyone! Installed Guix, but can't load at system. Have something one  "Grub 2.0...   Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions." No one live-CD don't load. What to do with it??
<unmatched-paren>Guest5: you installed with the installer?
<unmatched-paren>i think i might know your problem
<unmatched-paren>because the installer, for some reason, does not wipe the boot partition by default.
<unmatched-paren>it just adds a new grub without getting rid of the old one
<unmatched-paren>so the old grub is picked up
<unmatched-paren>and of course it can't find the wiped OS that it's supposed to boot to
<unmatched-paren>so it drops you into a grub shell
<unmatched-paren>you need to check the "wipe partition" or something similar box in the settings for /boot/efi when setting up the partitions
<unmatched-paren>can't remember the exact procedure
<unmatched-paren>i think you press "Enter" on the partition's menu entry, which drops you into an options box in which one of the toggles is "wipe partition"
<unmatched-paren>it wipes the other ones by default, but not /boot/efi... no idea why, i think it was just a mistake
<apteryx>uh, I think we need to advice our users to specify a lower --iter-time for LUKS keys -- a freshly created LUKS partition takes like 3 minutes to unlock
<apteryx>(at boot by GRUB)
<Guest5>Hi everyone! Installed Guix, but can't load at system. Have something
<Guest5>one  "Grub 2.0...   Minimal BASH-like line editing is supported. For the
<Guest5> first word, TAB lists possible command completions. Anywhere else TAB
<Guest5>lists possible device or file completions." No one live-CD don't load.
<Guest5>What to do with it??
<unmatched-paren>Guest9533: see my comments above
<unmatched-paren>uh, apparently the guy just left
<ardon>I'm trying to set up a service for a package that writes "session" files to its application directory (inside /gnu/store) so I get read-only errors. However, I can override this with an environment variable. How should I decide if this fits a system service or a home service best? If it was the latter I'd probably choose ~/.cache to store them, but where would I place them in the case of a system service? /var/application_name or
<ardon>/opt/application_name ?
<Guest5>Hi everyone! Installed Guix, but can't load at system. Have something
<Guest5>one  "Grub 2.0...   Minimal BASH-like line editing is supported. For the
<Guest5> first word, TAB lists possible command completions. Anywhere else TAB
<Guest5>lists possible device or file completions." No one live-CD don't load.
<Guest5>What to do with it??
<unmatched-paren>Guest5: hi, i responded to your question above, but it seems like you missed them.
<unmatched-paren>would you like me to repost my reponse?
<rekado>Guest5: ^
<unmatched-paren>rekado: ah, yeah, linking to the logs is a better idea
***mark_ is now known as mjw
<vagrantc>for trivial reproducible builds fixes, should i submit to guix-patches, or just commit them?
<sneek>vagrantc, you have 1 message!
<sneek>vagrantc, zimoun says: thanks for sharing the workflow.
<vagrantc>e.g. there are a couple that are basically just changing (invoke "gzip" ...) to (invoke "gzip" "-n" ...)
<rekado>vagrantc: given the current review situation I’d say: push them if you’re confident about them and they don’t lead to big rebuilds.
<vagrantc>i guess fewer of the gzip ones than i thought
<vagrantc>ok, 3 reproducible builds fixes and two from yesterday ... only ... 1069 more to go! (and 2289 unknowns ...)
*vagrantc wonders why surfraw builds reproducibly
<vagrantc>oh, it passes the longhand option for some reason
<vagrantc>though i don't see where it gets the --no-name argument from...
<rekahsoft>Hi folks, I run a local cuirass instance and have noticed that since the emacs-28 update, emacs-deferred is stuck (its been stuck for a week or more now). I noticed that this briefly came up previously here (, but no further discussion really occurred. Any idea on how I can resolve this?
<unmatched-paren>rekahsoft: i think this might be fixed now?
*unmatched-paren checks
<rekahsoft>unmatched-paren: My understanding is that is has been fixed, however I can't get my cuirass instance to stop trying to rebuild the seeminly broken emacs-deferred package
<rekahsoft>unmatched-paren: Eg. there is already a substitute of emacs-deferred built on (
<unmatched-paren>rekahsoft: ah, i see, it's trying to build older commits? not familiar with cuirass, i'm afraid.
<rekahsoft>unmatched-paren: I'm not very familiar either. I also don't build all packages on my local cuirass instance, so I think my setup of cuirass is a little different then the primary guix/bordaeu instances. Thanks for your input unmatched-paren :) I'll keep digging when I have some spare time.
<nckx>vagrantc, reproducility champ: Would it make sense for gzip to imply -n when SOURCE_DATE_EPOCH is set, or is that too inflationary?
<vagrantc>nckx: not sure ... what's weird is not using -n/--no-name actually just doesn't embed the filename and corresponding timestamp of the filename ... the timestamp is kind of a side-effect
*vagrantc hopes there weren't any sign errors in that
<nckx>Right, that's the ‘inflation’ I alluded to. Whether S_D_E should strictly affect timestamps and nothing else, or if tools can/should interpret it as a more general ‘ay, we tryin' to be reprodoosible ova here’.
<vagrantc>there are definitely upstreams which act on SOURCE_DATE_EPOCH for non-timestamp things
<nckx>I poked around the RB site but didn't really find a hard answer.
<vagrantc>which is weird but ... butter than staying unreproducible
<nckx>Ah. Thanks.
<vagrantc>butter, better, etc. :)
*vagrantc is partial to olive oil
<vagrantc>i mean, my biased opinion is that things should be reproducible by default... you shouldn't have to set any special flags, environment variables, etc.
<nckx>Yes, I agree. If I were king of gzip I wouldn't store the file name at all.
<vagrantc>or... store the file name and just not it's timestamp ... :)
<ternary>I have my own custom guix channel that I experiment in, but recently doing a `guix pull` has broken completely unless I disable that channel and I have no idea why
<unmatched-paren>ternary: can you share the error?
<unmatched-paren>and also the guix channel's source code link, if there is one?
<ternary>I get this error every time: "builder for `/gnu/store/han93b2v5sw24j7kz4083i4ya1ba84pg-najer.drv' failed to produce output path `/gnu/store/6mb71zy1d6j38nsm9zc5irh7s0k9vi37-najer'"
<nckx>ternary: You're probably referring to a variable that was removed, such as libpng-1.2 was recently.
<unmatched-paren>ternary: ah, we'll need to see your najer package
<ternary>najer is the channel. There isn't a package like that
<unmatched-paren>oh, right
*unmatched-paren wishes guix lint had a --file option or possibly --load-path-only
<ternary>nckx: Is there a way to see what would be failing, or do I just need to roll some commits back?
<unmatched-paren>ternary: try running `guix lint` on some of your packages
<unmatched-paren>with `guix lint -L . PKG`
<unmatched-paren>in the channel's root dir
<nckx>ternary: I'm pulling it now.
<ternary>Alright, I'll start giving that a go
<unmatched-paren>(which is why i was wishing there was a --file option; it'd make it a lot easier :)
<maximed>Hi #guix
<maximed>Has someone thought about step (b) of <>?
<maximed>i.e., build antioxidated package as a channel in CI to have a better idea of how much remains to be done
<maximed>nckx: yo
<nckx>IWBN if notabug were up.
<maximed>nckx: I've for now made a copy at
<apteryx>civodul: how easy would be to allow some DWIM with the transformation option, for example to act on the package provided on the command line when there's only one? E.g. b python-robotframework --with-commit=python-robotframework=c328b943623fe9840f533a2a0b568edb805870ef --with-git-url=python-robotframework=file:///home/maxim/src/robotframework --> b python-robotframework
<apteryx>--with-commit=c328b943623fe9840f533a2a0b568edb805870ef --with-git-url=file:///home/maxim/src/robotframework
<nckx>maximed: Right, that's the one I was looking at. As long as it remains updated
<jpoiret>apteryx: not worth the trouble i'd say
<maximed>Would be nice to someday teach the channels code (and git-checkout and git-fetch) about fallback locations.
*nckx pulls the GitHub channel in the mean time.
<maximed>warning: some crates were updated/added (to resolve build failures) without checking their source code for malware or such
<civodul>apteryx: not sure if it's feasible, maybe it is
<nckx>I have no idea what Cuirass supports as ‘custom’ parameter, so I'm just going to throw random Scheme in there until it works.
<maximed>so running the build results is currently risky
<maximed>(building should be fine as long as there are no holes in the build container)
<apteryx>civodul: didn't we already had such thing but for just one of the transformation option?
<civodul>apteryx: --with-source is "shallow", yes
<civodul>so it's not impossible, but looking at (guix transformations), it's not trivial either
<maximed>... which exist even assuming that Guix containerisation is perfect because of rowhammer
<civodul>because of the way things are written
<civodul>(i agree less verbose options would be nice tho)
<apteryx>"the way things are written" being implementation details?
<nckx>maximed: I admire and support your rigour in that regard (and have taken to upping my own because of you), but we're not strictly worse off than any other distribution that just uses cargo, right?
<maximed>nckx: in that regard = updating crates?
<nckx>Auditing source.
<maximed>I don't really know how much other distros do that
<nckx>ternary: I get the message ‘/var/log/guix/drvs/f9/317p58j2vjxr5zgjqv444aqx8r3fx1-najer.drv.gz’
<nckx>Sorry: ‘View build log at '/var/log/guix/drvs/f9/317p58j2vjxr5zgjqv444aqx8r3fx1-najer.drv.gz'’
<nckx>Strange that you did not.
<maximed>Debian does some auditing though (the degree of which varies, and it seems to be mostly licensing-wise instead of malware-wise)
<nckx>Anyway, clarity awaits you in that log file.
<maximed>so there's a chance we're worse off than Debian here.
<vagrantc>i'm gonna guess some race condition due to parallelism:
<nckx>I have no idea whether Debian falls under ‘just use cargo’. Doesn't fit my stereotype of them.
<nckx>vagrantc: Eek.
<maximed>nckx: Debai uses cargo, but they don't just use cargo
<maximed>* Debian
<apteryx>civodul: a more serious problem though, --with-commit=... needs to come after --with-git-url=..., otherwise it appears silently ignored
<maximed>E.g., they were able to remove the winapi, cocoa, ... crates
<maximed>(by patching the Cargo.toml)
*nckx runs another Guix pull to get the antiox goodness. I know this will be news to everyone, but boy is guix pull slow.
<ternary>nckx: Yeah that is weird I didn't get that. I just barely caught that with the linter as well and it seems to have fixed the problem
<vagrantc>debian is pretty much like guix in that there are policies and processes and never enough volunteers to do it all (although a significantly larger pool of volunteers)
<nckx>ternary: I didn't run with any verbosity setting either. Weird.
<maximed>they also loosen versions sometimes ( ha smore details)
<nckx>maximed: I can't pull it as a channel.
<nckx>I've got (too) many channels. I didn't test removing everything else.
<ham5urg>Is it possible to install an app for all users? Something like 'guix system install neovim'?
<maximed>Oopsnckx: Most of those are technically warnings, not errors (though still maybe the last part of antioxidant-ci.scm should be removed)
<maximed>the error is python-temppatlib
<nckx>ham5urg: Add it to your system.scm's operating-system's (packages …) field.
<maximed>nckx: python-temppathlib is not part of Guix or antioxidant
<maximed>and not used in Guix or antioxidant
<nckx>I thought for a sec my file:///home/nckx/guix ‘channel’ was out of date.
<unmatched-paren>nckx: crap, just noticed that i'd broken guixrus with a python-temppathlib unbound variable, if you're using guixrus?
<unmatched-paren>somehow my extensive linting didn't catch it
<unmatched-paren>pull now, it should wrok
<nckx>Yes, I'd just found it and was getting my pitchfork.
<nckx>2 seconds later and I would have hit return.
<nckx>Lucky you.
<unmatched-paren>I'm somehow very good at breaking guixrus. I should test my changes more thoughroughly...
<nckx>We'll never let you break Guix at this rat.
<nckx>Let's not type anything ever again.
<unmatched-paren>nckx: yeah, i was about to say: at least you all know never to give me commit access to guix.git! :D
<nckx>By the way, unmatched-paren, do you get an absolute tonne of (IIRC) package shadowing warnings when using that channel?
<nckx>I was going to report it; haven't yet.
<unmatched-paren>nckx: yes, it's because it packages later versions of various rust crates than what is in guix
<unmatched-paren>and some modules import both (gnu packages crates-io) and (guixrus packages common rust), of course
*unmatched-paren .oO(maybe i should change them to use different names)
<nckx>Tedious to hand-herd #:hides and #:selects, I understand.
<unmatched-paren>nckx: ...i could also do that, i guess.
<nckx>Tedious in general, Rust packaging.
<nckx>You could, but I didn't blame you for not doing it.
<unmatched-paren>At least Rust has nice versioning. Go projects just pin their deps to random commits. it's very annoying.
<unmatched-paren>Go is currently stopping me from having a decent email client >:(
<nckx>Go is a dead end. I'm glad that it doesn't seem to be catching on as much as Rust is, despite aggressive pushing by Googlers.
<nckx>I wasn't going to do this.
*nckx shats up.
<nckx>unmatched-paren: It worked! Thanks.
<unmatched-paren>nckx: you have nothing to thank me for, i broke it in the first place
<nckx>This guixrus is some kind of protection racket.
<nckx>But thank you [all] for difftastic, it helped me get past some diffoscope flaws.
*vagrantc chuckles at the difference between "guix challenge" and "guix challenge PACKAGE"
<vagrantc>one takes notably longer
<unmatched-paren>vagrantc: does the former challenge everything? :P
<civodul>it seemed like a good idea for "guix challenge" to challenge *everything* in your store back then
<civodul>(not just every package, literally every store item)
<vagrantc>is it just what's in the store?
<civodul>but in hindsight that sounds silly, no?
<vagrantc>seems like it wouldn't be the worst breaking change to have it do that with an explicit argument
<apteryx>sounds a nice feature for the paranoid (have I been compromised?)
<unmatched-paren>petition to add a `guix challenge --literally-everything` that just prints "your political opinions are bad"
<unmatched-paren>actually s/political//
<civodul>if you could do "guix challenge $(guix gc --list-live)", that'd be equivalent
<vagrantc>it's a great feature, it's just non-obvious how to trigger it
<civodul>i don't think "guix challenge" accepts store file names right now, tho
<vagrantc>and easy to accidentally forget to pass the package you want and suddenly it's doing wierd things
<vagrantc>or ... doing more than you intended to ask for
<vagrantc>currently on a foreign distro, i'm getting lots of "warning: failed to delete /tmp/guix-directory.QdS8uX: Directory not empty" after running guix challenge --diff=diffoscope PACKAGE
<vagrantc>and the failures actually obscure the diffoscope output in many cases
<vagrantc>don't have a Guix System handy to check if that's working fine there...
<vagrantc>i guess more notably "warning: failed to delete /tmp/guix-directory.QdS8uX: Directory not empty"
<vagrantc>warning: failed to delete /tmp/guix-directory.QdS8uX/share: Permission denied
<unmatched-paren>in fact, why not add literal versions of everything where it makes sense? `guix gc --literally` scans $HOME for terrible-looking code and deletes it, `guix weather --literally` fetches the latest weather report for your area, and `guix remove --literally` completely uninstalls guix from your system (with full Guix System integration; if you're using it, it wipes your disk!)
<vagrantc>dr-xr-xr-x 4 vagrant vagrant 4096 Dec 31 1969 share
<vagrantc>well, i guess that explains it
<unmatched-paren>`guix time-machine --literally`'s effect is obvious. :P
<unmatched-paren>`guix describe --literally STRING` searches for a wikipedia page titled `STRING` and prints the entire thing* to the terminal! *HTML removed
<maximed>* unmatched-paren: guix install gnucash --literally
<unmatched-paren>maximed: genius. we'll all be rich!
<maximed>... but does it only install cash, or does it also imply "guix remove gnucash --literally" for someone else?
<vagrantc>really dillutes the value of gnu bucks
<unmatched-paren>maximed: Money isn't everything, you know: `guix install ghc-happy --literally`
<maximed>also "guix install love"
<unmatched-paren>oh, hey, forgot about LÖVE
<nckx>guix substitute love
<nckx>→ free beer \o/
<unmatched-paren>`guix home reconfigure --literally` redecorates your house, `guix refresh --literally` searches for a web browser running and sends it an F5 key press event, but I haven't yet mustered the courage to see what `guix lint --literally` does.
<nckx>Unfortunately, you are literally 2 months & a day late.
<maximed>LANGUAGE=nl_NL guix publish --workers=4: let four people bake a cake
<maximed>nevermind, also works in English
<unmatched-paren>`guix publish FILE.tex --literally` compiles the TeX file into a PDF and sends it to a randomly selected publisher.
*maximed guix shell sleep --literally -- sleep
<ham5urg>When I enter 'guix system reconfigure' I get a 'wrong number of arguments for action reconfigure'. Why is that?
<unmatched-paren>`guix import crate ... --literally` involves a Cargo ship :)
<nckx>ham5urg: You need to specify which file to use.
<unmatched-paren>ham5urg: /etc/config.scm usually
<nckx>The one containing your o-s definition.
<nckx>Here, that's /etc/guix/system.scm.
<nckx>Yours might be different.
<unmatched-paren>mine is ~/conf/system.scm, but /etc/config.scm is the default
<ham5urg>Yes, I thought it would be used if none is given. tells 're-running guix system reconfigure.' which let me to that assumption.
<ham5urg>Thanks, it worked like a charm.
<ham5urg>Guix is quite capabale. No Debs, no Ansible any more :D
<civodul> <- some interesting takeaways from folks who tried Guix System
<civodul>(and also some less interesting ramblings, HN is HN)
<unmatched-paren>civodul: what kind of interesting takeaways, may i ask? (I blocked it in /etc/hosts for my own sanity :P)
<unmatched-paren>ham5urg: are you currently using Guix Home? If you like using config.scm you'll like it :)
<apteryx>civodul: I was wondering what #:namespaces (delq 'net %namespaces) was for in the opendht service least-authority-wrapper adaptation
<apteryx>this is needed when processes must talk with the host network?
<vagrantc>what's the difference between (arguments '(#:phases (modify-phases %standard-phases ... `(#:phases (modify-phases %standard-phases ... (list #:phases #~(modify-phases %standard-phases
<vagrantc>i see all three used in gnu/packages/code.scm
<unmatched-paren>vagrantc: the first two are indistinguishable and deprecated
<unmatched-paren>except the quasiquote allows unquoting of cours
<unmatched-paren>the third is now encouraged afaicr
<unmatched-paren>although e.g. string arguments shouldn't be gexped
<civodul>apteryx: exactly
<civodul>it lets opendht access the "global network namespace"
<julia-l>is there an easy way to manage file/directory permissions with guix home? I'm trying to use home-xdg-configuration-file-services-type to manage my GPG config, and gpg expects it's config dir to be 700
<civodul>so IOW, it lets it talk to the outside world
<vagrantc>the '( and `( styles seem much more common?
<unmatched-paren>vagrantc: i think (list ...) being encouraged is quite a recent thing
<julia-l>afaict the best way to do this is to write my own service
<civodul>julia-l: hi! hmm right, i'm not sure one can specify permissions
<civodul>OTOH, those files are necessarily world-readable in the store
<civodul>but yeah, for directories it'd be nice to change permissions
<ham5urg>unmatched-paren, just doing my first steps with guix inside a VM.
<vagrantc>unmatched-paren: neither guix lint nor guix style are very opinionated about it
<unmatched-paren>vagrantc: i guess if the former raised warnings for old argument style, there'd be way too many of them
<johnjaye>hey i heard guix is complicated and doing crazy things. came here to find out what
<unmatched-paren>johnjaye: oh hey :P
<nckx>civodul: ‘uix will behave as if the root directory of that channel’s Git repository has been added to the Guile load path’ — OK, but when I add <> as a channel, guix repl doesn't find (antioxidant). -L . works fine. What'm I missing?
<johnjaye>heyo. point me to the scheme station and let's see what's on tap
<unmatched-paren>(I briefly mentioned guix in #c to johnjaye :P)
<civodul>nckx: it's a weird bu^W feature: you first have to ,use(gnu packages) at the REPL, and then you'll be able to see the modules of that channel
<ham5urg_>A line like '(packages (append (list (specification->package "nss-crets")) %base-packages))' is in my config.scm. I guess (append ...) expands to a list of packages. Am I right? How to add neovim into that? I've put '(append ...) neovim' but got an error.