<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 <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 <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 https://paste.debian.net/1242757/ ... 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. <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>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>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 " <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>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>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 <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!) <munksgaard>Is there a quick way to find the path to the binary built by `guix build -f foo.scm`? <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 <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. <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 <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>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>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>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 https://github.com` I'm told that github.com 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 <nckx>‘guix search’ highlighting is a nice new touch. <civodul>avalenn: hey! yeah i saw it earlier today ***IHateSpecing is now known as IForgiveSpecing
***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). <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. <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 <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_>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 https://transfer.sh) 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>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” <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>because the installer, for some reason, does not wipe the boot partition by default. <unmatched-paren>and of course it can't find the wiped OS that it's supposed to boot to <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>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 <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. <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 <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. <unmatched-paren>Guest5: hi, i responded to your question above, but it seems like you missed them. ***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 (https://logs.guix.gnu.org/guix/2022-05-15.log#131636), but no further discussion really occurred. Any idea on how I can resolve this? <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 <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 *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 <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. <ternary>najer is the channel. There isn't a package like that *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? <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>i.e., build antioxidated package as a channel in CI to have a better idea of how much remains to be done <nckx>IWBN if notabug were up. <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? <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. <nckx>I have no idea whether Debian falls under ‘just use cargo’. Doesn't fit my stereotype of them. <maximed>nckx: Debai uses cargo, but they don't just use cargo <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 *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. <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) <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 <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? <nckx>Yes, I'd just found it and was getting my pitchfork. <nckx>2 seconds later and I would have hit return. <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. <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. <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>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" <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) <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" <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 <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 <maximed>... but does it only install cash, or does it also imply "guix remove gnucash --literally" for someone else? <unmatched-paren>maximed: Money isn't everything, you know: `guix install ghc-happy --literally` <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 <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? <nckx>ham5urg: You need to specify which file to use. <nckx>The one containing your o-s definition. <nckx>Here, that's /etc/guix/system.scm. <nckx>Yours might be different. <ham5urg>Guix is quite capabale. No Debs, no Ansible any more :D <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 <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 <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 <https://github.com/emixa-d/antioxidant-fallback/> 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 <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.