IRC channel logs


back to list of logs

<roptat>I'd like to say the same for armhf... :D
<roptat>maybe that was because we got one of the overdrives back in the build farm?
<vagrantc>oh, no so lucky as to have linux-libre tarballs prebuilt
<pkill9>evening guix
<kcurtet>Hi, someone knows what are the error `bad-response' In procedure run-guix-command
<kcurtet>When i try to install something i need to repead the guix command to complete the builds because of this error
<kcurtet>I have good interner if anyone thinks is that.
<jlicht>kcurtet: I've had this happen recently as well. In most casing, retrying 'fixed' the problem for me.
*jlicht -> zzz
<kcurtet>I also "solved" the issue adding --no-subtitutes and build the packages in my machine
<kcurtet>I'm not sure if -c`nproc` its the default cpu to utilize
<arxbrt>lle-bout, nckx: Sorry I slept eight hours before, and just wake up now.
<arxbrt>lle-bout: my (setuid-programs ..) entry is same as you sent to me. A strange situation is that when I login with ssh, `which sudo` point to `/run/current-system`
<arxbrt>lle-bout: But when I login with tty, `which sudo` point to `/run/setuid-programs/sudo` and `sudo` worked correctly
<arxbrt>lle-bout: Though `which ecryptfs-mount-private` point to `/run/setuid-programs`, it didn't work and setreuid error occured also
<raghavgururajan>Hmm. Why there are too many builds during guix pull, recently?
<arxbrt>nckx: I thinks it's not a problem that is easy to solve quickly, maybe I should consider a alternative plan
<arxbrt>lle-bout, nckx: Thanks again for your help
<Whyvn>i am still trying to learn correct scheme formatting and applying it from the documentation. I want to enable the bluetooth service, would I just add something like (service bluetooth-service #:auto-enable #t) to the appended list of services under operating-system?
<apteryx>(services (cons* (bluetooth-service #:auto-enable? #t) %desktop-services))
<apteryx>with (use-service-modules desktop [...]) at the top of your config.scm file
<apteryx>because the bluetooth-service and the %desktop-services variable are defined within the desktop service module (gnu services desktop).
<Whyvn>apteryx: thank you
<apteryx>you are welcome!
<apteryx>avalenn: hey, it seems the latest protobuf cleaned its bootstrap path quite a lot
<apteryx>released two days ago
<bdju>what should a channels.scm file look like if I just want the normal repo? I wanted to remove a channel I had listed with cons + %default-channels but it's not working. deleting the file seems extreme
<bdju>I guess I don't care that much. I'll delete the file. the manual didn't have an answer either
<xelxebar_>bdju: It looks like channels.scm just contains a list of `channel` objects. %default-channels is, indeed, already a list of just that.
***amfl_ is now known as amfl
<janneke>wingo, spk121: looking at it now, after wingo's comment i'm wondering if we shouldn't use size_t, ssize_t instead of intptr_t, uintptr_t throughout?
<janneke>or possibly (try to) distinguish between where "pointer/pointer sized" is intended (*inttptr_t) and where it's a number/fixnum (*size_t)
***koleesch_ is now known as koleesch
<leoprikler>is this for Guix or for guile?
<janneke>leoprikler: ah, yes for #guile -thanks
<yoctocell>Does anyone know what the differences between emacsy and emacsy-minimal are?
<yoctocell>In what way is emacsy-minimal more minimal?
*mbakke picks up their unfinished TeX Live 2020 and GCC 10 work after a three month hiatus
<nckx>yoctocell: emacsy's closure was about 10x that of emacsy-minimal (which was added for Nomad). Now, the difference is that emacsy-minimal builds whilst emacsy doesn't, and the two have drifted apart.
<nckx>But when minimal was added it omitted all propagated-inputs and disabled examples.
<yoctocell>nckx: Ok, thanks for the explanation
<nckx>emacsy-minimal could just as well be called emacsy-for-nomad; no other users.
<zzappie>Hello guix!
<zzappie>Has anyone tried to create lightweight docker containers with single store shared among them?
<zzappie>In the same spirit as guix system vm
<clacke>zzappie: pretty sure I read about Guix or Nix people just mapping the local store into the container as a volume, and I see no reason it wouldn't work
<cdegroot>My two cents are: why, if `guix environment --container` works so well. Much better, if you ask me.
<kisaja[m]>Oh great im not the only bad response guy
<nckx>We all are.
<kisaja[m]>Because i have that talent to find two unrelated bugs at the same time lol
<zzappie>clacke: Yep It should work but in my case it doesnt help since I was looking for a way to manage store by docker container and sharing it with other instances.
<zzappie>cdegroot: Yes of course. But people speak docker nowadays. I'm in the process of sharing my guix based workflow with others
<mbakke>apteryx: I could use some assistance regarding a TeX Live upgrade when you have the time :-)
<mbakke>in particular, some files from kpathsea are missing from texlive-latex-base in the new version
<mbakke>I don't have the original branch to compare with, and 2019 won't build on my branch (with GCC 10 and some other low-level changes)
<mbakke>things work if kpathsea is propagated, but I suppose copying/symlinking the relevant scripts is the way to go
<mbakke>ooh, generic-html-updater, nice
<mbakke>lle-bout_: I looked into the chromium crash on and found that it works with '--disable-features=UseSkiaRenderer', suggesting a problem with the Skia acceleration.
<mbakke>possibly a conflict between Mesas libGL and Chromiums ANGLE
<mbakke>unfortunately it does not crash when run through a debugger, instead just hangs indefinitely
<mbakke> attempts at building a debug-enabled chromium binary have so far not been successful
<mbakke>is it possible to define a replacement (graft) for a gexp?
<jonsger>who broke my sysctl service :(
<mbakke>jonsger: maybe 898489f48e436e45e86e1ba0fcdb6df5cd5a051a ?
<roptat>oh btw my guix pull succeeded, it officially took me three days to complete, not bad ^^'
<roptat>running reconfigure now
<jonsger>mbakke: thanks :)
*jonsger wonders how many years it will takes until every service is lying under modify-services %base/%desktop-services :P
<civodul>hey mbakke!
<civodul>mbakke: "replacements" are only for packages; what would it mean for a gexp?
<civodul>roptat: 3 days, that's on armhf-linux?
<mbakke>civodul: Long time no see! Real life hit me hard recently. :-)
<civodul>mbakke: d'oh!
<mbakke>civodul: I have a package that uses a local-file as input, and want to define a replacement for the local-file without rebuilding the package.
<vagrantc>roptat: what armhf system?
<civodul>mbakke: woow, that's power usage
<civodul>it's not possible currently
<civodul>if you managed to turned that local-file into a package, you could do it
<vagrantc>updated the pinebook-pro yesterday for the first time in ~6 weeks
<vagrantc>should try updating the veyron-speedy today...
<mbakke>civodul: I see. Sounds like we might need a grafting machinery for gexps eventually, especially now with gexp-build-system?
<Telc[m]>vagrantc: can I ask you some questions about the debian package? thats you right?
<Telc[m]>I noticed some issues with the install like there were no gpg keys installed one of the daemons didn't start, and there was no /gnu directory created
<vagrantc>Telc[m]: curious ... worked out of the box for me ... are you running with something other than systemd?
<Telc[m]>no this was a debian testing with/unstable/experimental
<Telc[m]>also some form of readme in /usr/shared/doc/guix/ would be good
<Telc[m]>if i had to guess the issue with the lack of /gnu it was the lack of imported gpg keys
<Telc[m]>but I'm just getting my feet under me with guix still
<vagrantc>Telc[m]: not sure what you mean by imported gpg keys ...
<vagrantc>Telc[m]: during guix pull or something?
<Telc[m]>ah sorry it was an error in one of the daemons starting
<vagrantc>Telc[m]: i guess i should try with a fresh install
<Telc[m]>i apologize, i backed out the install as it was almost my first experience with guix
<Telc[m]>i should have grabbed the logs
<Telc[m]>i can look to see if they are around
<vagrantc>Telc[m]: also, feel free to report bugs against the package to make sure things don't get lost in the cracks
<Telc[m]>vagrantc: sure, sorry looks like they purged but ill try a new deb install in a few days probably
<roptat>civodul, vagrantc yes armhf, it's a cubitruck, but I was mostly stuck because glib didn't build, had to find a way to fix
<roptat>now building git
<roptat>also I'm not complaining, I'm being very patient and appreciative of all the work that everyone did to make all this even possible
<vagrantc>Telc[m]: ah! guix-publish is entirely optional ... but i guess it shouldn't try to start out-of-the-box then
<vagrantc>Telc[m]: can you file a bug, and i'll try and get it fixed soon
<Telc[m]>i probably wont dive too much more deeply then
<vagrantc>Telc[m]: just what you listed there and a little prose description would be plenty
<Telc[m]>whats the goal with the package overall?
<Telc[m]>grandplans or just an easier onramp for debian users?
<vagrantc>Telc[m]: to a large extent, a trust path to guix if you're already running debian
<vagrantc>but in the end i'd expect people to mostly be running "guix pull"
<vagrantc>the process of packaging it also did a bit of quality assurance checks against some assumptions in guix :)
<Telc[m]>ports can do that :)
<vagrantc>Telc[m]: but i need to fix a security bug in it ideally before release, fixing the bug you found can probably fit into it ok
<Telc[m]>as a user im inclined to see if i can use guix to setup a solid user space
<Telc[m]>maybe fold emacs and some nicetohaves into new workstation installs
<Telc[m]>yeah i dont know what to say about the lack of "/gnu" after the install
<Telc[m]>if it wasn't the missing key
<vagrantc>wow, been a while since i updated this armhf machine: Authenticating channel 'guix', commits 9edb3f6 to 46479ec (7,719 new commits)...
<Telc[m]>id also like to use guix for container builds and see where its at with the pine64 ecosystem
<vagrantc>Telc[m]: ah, i've got ... too many pine* systems :)
<Telc[m]>yeah its hard not to overdo it
<Telc[m]>there is a nixos install for it
<vagrantc>pinebook*, pine64_plus, and more recently pinephone ... soon to get the risc-v soldering iron too :)
<Telc[m]>which ui are you on with pinephone?
<vagrantc>well, i got the mobian variant, but intend to work on plain debian and guix, of course :)
<Telc[m]>that'd be really nice
<Telc[m]>i haven't tried phosh but the kde phone bits are pretty nice
<vagrantc>phosh is pretty cool :)
<vagrantc>haven't tried the kde stuff
<Telc[m]>if my phone was just another linux host with all the amenities life would be grand :)
<Telc[m]>this was all I found so far guix
<Telc[m]>that about where its at atm?
<vagrantc>oh wow
<vagrantc>wasn't aware someone already started on it
<mbakke>I wonder why ced3d5cbf99eac429a45e33191335ec0662f1df3 was necessary, would it not be sufficient to adjust the "faketime" invokation?
<mbakke>*invocation, sorry lfam
<mbakke>apteryx: ^
<pkill9>does anyone know of a way of viewing a simple indented text file with the ability to collapse the indentations?
<Telc[m]>pkill9: both emacs and vim have code folding
<pkill9>i looked into it but it was a bit clunky, didn't try with emacs
<davidl>How can I create a container that runs cuirass? After creating a container with an OS config that contains a cuirass service I am getting an error saying that says that remounting cuirass is an operations that is not permitted.
<davidl>remounting /gnu/store* is not permitted
<pkill9>ok i have tried emacs-origami and it is working very nicely
<pkill9>although it is folding siblings into above
<Telc[m]>depending on what you are trying to accomplish orgmode might get you there the fastest
<Telc[m]>its folding is quite good and can be bound to vim friendly keys (there are some in evil-collection already)
<pkill9>where do i start with orgmode? ive never tried it, i don't really know emacs either
<davidl>pkill9: search for "moving in bubb
<davidl>pkill9: search for "moving in buffers" here:
<davidl>pkill9: and then you have the emacs manual:
<pkill9>tbh I know how to switch buffers, and i have evil mode installed
<pkill9>i guess if i just ignore the other functionality it works fine
<pkill9>it can just get confusing if I delve more into it
<pkill9>anyone know how to solve git: 'remote-https' is not a git command. See 'git --help'.
<nckx>No, but I get an amusing error of my own:
<nckx>~ λ git remote-https → error: remote-curl: usage: git remote-curl <remote> [<url>]
<nckx>~ λ git remote-curl → git: 'remote-curl' is not a git command. See 'git --help'.
<nckx>pkill9: When exactly does that happen?
<pkill9>when i try to git clone
<nckx>I thought it might be a profile or path issue (like installing git & git:send-email into 2 different profiles won't end well), but can't reproduce it with ‘git clone’ in a pure environment with only git & nss-certs.
<nckx>guix environment --pure --ad-hoc git nss-certs -- git clone /tmp/blerp
<nckx>Does that work for you pkill9?
<pkill9>yes that works
<pkill9>i guess my environment is borked somewhat
<jlicht>ello guix!
<nckx>pkill9: I guess your mission is to find out the difference in env between the two; not something we can help with ☹
<nckx>\o jlicht.
<pkill9>found the issue
<nckx>What was the broken value?
<pkill9>probalby because I have .profile sourcing default guix profile again so the paths are absolute
<pkill9>i'll test without
<pkill9>now it works
<pkill9>this works and is populated with many git-* commands
<nckx>Yeah, that looks sane. Here it's /run/current-system/profile/libexec/git-core (because my git is a system package).
<pkill9>now it works again, i know why, it's because i didn't have git installed to my profile before
<pkill9>and because I made it use absolute path to profile, it didn't update
<pkill9>when i installed git
<pkill9>i've set it to /var/guix/profiles/...
<roptat>ok, php and git have built successfully, now building guix itself
<screwedupgrub>hello guix!
<screwedupgrub>I just ran system reconfigure and it screwed up my grub
<roptat>how so?
<screwedupgrub>don't know but system wont load im on ubuntu live cd stick now
<nckx>What does the bad GRUB do -- exactly -- when you try to boot it?
<screwedupgrub>well I don't see it at all
<screwedupgrub>I see some lenovo built in menu asking what to load
<nckx>screwedupgrub: From the rescue system, does ‘efibootmgr’ print anything Guix?
*screwedupgrub apt installing efiootmgr
<nckx>[Running ahead here but need to go AFK] If it doesn't, you can try creating a boot entry for Guix with ‘efibootmgr --create --disk <your /boot device, e.g., /dev/sda> --part <your /boot partition number> --loader '\EFI\Guix\grubx64.efi' --label Guix’.
*nckx → AFK.
<screwedupgrub>nckx Thanks!
<screwedupgrub>not sure that it could show anything tho because I hav encrypted install in nvm
*screwedupgrub ah okay boot not encrypted
***lle-bout` is now known as lle-bout
*nckx ret.
<nckx>screwedupgrub: I made a thinko. It should be your *EFI* partition's device and number (so whatever you'd mount at /boot/efi), not /boot's (which is probably /, since Guix System doesn't support separate /boot AFAIK).
<nckx>So there was no ‘Guix’ entry already present in the ‘efibootmgr’ output?
<screwedupgrub>nckx there was nothing labeled as Guix no
<rekado>“guix build -d” shows the derivation to be built; “guix package” has no such option. Is there a convenient way to get the derivation of a profile without having to parse the output of “guix package -n -m manifest”?
<nckx>screwedupgrub: Which machine is this? My also-Lenovo X230T has forgot the Guix boot entry once or twice in the past, for what appeared to be no reason.
<rekado>“guix build -d -m manifest” shows not the derivation of the profile but the derivations of the individual packages to be built.
<screwedupgrub>nckx nope its T570
<screwedupgrub>nckx what is '--part <your /boot partition number>
<nckx>I've made a copy (no symlinks on FAT ☹) of \EFI\Guix\grubx64.efi as \EFI\boot\bootx64.efi (the UEFI default) for that reason, but of course it could become outdated so I can't say it's a remedy.
<nckx>screwedupgrub: If your EFI partition is /dev/sda4, --device is /dev/sda and --part is 4.
<nckx>So that should have been ‘/boot/efi’.
<nckx>It would have been trivial for efibootmgr to parse /dev/sdxN itself but nope, its UI is generally horrible.
<screwedupgrub>aah and if its nvme0n1p1 then it should be --part 1 ? :)
<nckx>Your storage technology is strange and scary to me.
<nckx>(I don't know.)
<screwedupgrub>well i guess it is since the other one called nvme0n1p2
<nckx>I mean, it's pretty clear the p stands for partition, but I don't know what n is, or what your firmware sees.
<screwedupgrub>last thing before I run the command nckx :)   \EFI\boot\bootx64.efi -- Backslashes?
<nckx>Yes, but be sure to include the single quotes or you'll get (at best) an error.
*vagrantc hopes guix pull takes less than 3 days on the veyron-speedy
<vagrantc>speedy being a curious model name :)
<screwedupgrub>nckx okay thought for a second that backslashes is another irc funny thing
<screwedupgrub>all done trying to reboot
<southerntofu>hello, i'm new around here but i've been following the blog for a while, i'm curious if there's some chan/community dedicated to building selfhosting distribution with guix? (like a declarative yunohost)
*nckx looks up yunohost.
<nckx>Although I'm not aware of any such initiative. You mean self-hosting mail/chat/calendar/something like that?
<nckx>screwdupgrub: Welcome back.
<nckx>Sadly, if your nick is any indication...
<screwdupgrub>hello recurfaced on guix side!
<screwdupgrub>phew what a transactional upgrade that was!
<nckx>OK, now that we've put out the fire, yes, it should be noted that Guix (well, grub-install run by Guix) should have done all that for you.
<nckx>It's very strange that it didn't stick.
<screwdupgrub>big thanks nckx this was scary
<nckx>Do you remember any unusual/suspicious last lines after guix system reconfigure?
<southerntofu>nckx: yes that's what i had in mind! like functional/reproducible infrastructure for hosting cooperatives
<rekado>I came up with this clunker, but it gives me a different derivation: echo '(begin (use-modules (gnu packages) (guix derivations) (guix profiles) (guix store)) (derivation-file-name (with-store store (run-with-store store (profile-derivation (specifications->manifest (list "hello" "htop")))))))' | guix repl -t machine
<southerntofu>this usecase was briefly covered in 1.0 announcement:
<southerntofu>> That makes it surprisingly easy to deploy otherwise complex services such as applications (...) We’d love to see to what extent this helps people self-host services—sort of similar to what FreedomBox and YunoHost have been focusing on.
<nckx>screwdupgrub: I can't blame you for the ‘transactional’ quip, but you got very unlucky. The GRUB installation is the Achilles' heel in the whole process: we can't really do it transactionally, certainly not as long as we just trustingly invoke GRUB to do it.
<southerntofu>but i was curious if there was any development since then, or a place i could follow discussions about that
<rekado>the snippet above returns the same derivation as “guix environment -m manifest -n”, so maybe that’s good enough
<nckx>southerntofu: That's a pretty optimistic statement TBH. I self-host some services on Guix but there's still a lot of string and chewing gum keeping things together.
<nckx>However, the stringum is somewhat declaratively documented in a file instead of the result of running 325 commands 3 years ago, so there is certainly progress!
<screwdupgrub>nckx: I know :) just joking
<screwdupgrub>here is the cause
<nckx>Oh, thank you very much!
<nckx>So... that *didn't* happen in the rescue system? That's odd too.
<roptat>southerntofu, I'm also self-hosted with guix, but I don't think there's anything as easy to use as yunohost
<Telc[m]>packaging yunohost itself would be a good step along the way if thats interesting to anyone
<Telc[m]>and then work on the modifications to have it push scm files around
<southerntofu>nckx: the missing sentence i cut in the quote was giving links to one-liner examples for cgit and zabbix, though of course for more complex setup it's more complex
<southerntofu>roptat: i'm not looking for something like yunohost exactly, i mentioned it as an example selfhosting distro that takes care of configuring everything with sane defaults, but i don't care for the web interface or their package system in their precise implementation :)
<nckx>screwdupgrub: I wonder if that's something we *could* programatically recover from, and how...
<southerntofu>lately i've been using ansible to try and achieve semantic declarative config but i'm quite unhappy about ansible itself.. see for the interface for webserver config for example
<nckx>screwdupgrub: Would you have the time to report a bug describing your misadventures to bug-guix at With that output, and the fact that $distro's efibootmgr managed to write anyway...
<nckx>It's going to be forgotten otherwise.
<southerntofu>(where entire server is described in a global config file, but roles like the webserver can also be composed by other roles, so i'm programming my sysadmin in YAML and that's a terrible state of affairs :P)
***Noisytoot is now known as LPBot_
<southerntofu>i even wrote a draft article about my motivations for semantic sysadmin, if that's of interest to folks (critiques welcome):
<screwdupgrub>nckx: sure do you know is it possible to get more info on the issue? Maybe derivation builder source?
***LPBot_ is now known as Noisytoot
<nckx>southerntofu: Bookmarked for later reading.
<nckx>screwdupgrub: I don't even know if this part *is* logged, or where, which is why I was grateful for your verbatim paste.
<screwdupgrub>cool! Ill send the report tomorrow.
<nckx>Thank you!
<Telc[m]>southerntofu: i think if you are willing to spend some time with scheme/lisp you'll be overall pretty happy with guix
<Telc[m]>sometimes this just means letting your text editor having your balance your parantheses :)
<southerntofu>Telc[m]: it's crossed my mind on more than one occasion, but i was alraedy somewhat familiar with ansible so that's where i headed to experiment with :)
<Telc[m]>yeah ansible is pretty nice overall
<Telc[m]>but as others have noticed
<southerntofu>but i'd be much happier with a more consistent tooling and actually-reproducible builds with PGP signatures with proper trust bootstrapping (<3 channel introductions)
<Telc[m]>adding programming languages bits to a configuration language
<southerntofu>yes that's the wrong thing to do :)
<Telc[m]>tends to make some serious messes
<Telc[m]>lisp actually does lend itself to these problems
<southerntofu>Telc[m]: to be clear i don't know a single other person who uses ansible the way i use it.. because it's clearly not intended for somewhat-recursive logic :)
<jlicht>Telc[m]: solving them, or introducing them? :)
<Telc[m]>jlicht: of course tasteful use of your tools is always required
<Telc[m]>I could use that same response to southerntofu actually :)
<southerntofu>what part? you use ansible as a programming language yourself? :P
<Telc[m]>hopefully you spend enough time reading what the rest of the community writes in regards to code
<Telc[m]>so that you build some intuitions about sane use of the tools
<Telc[m]>no im pretty strict with ansible
<Telc[m]>very nice in moderation
<nckx>screwdupgrub: Did you happen to save the output of the first time we ran ‘efibootmgr’ in the rescue system?
<Telc[m]>but yeah its only so far
<nckx>screwdupgrub: If not, no problem, but do you remember roughly how many entries there were?
<southerntofu>Telc[m]: personally i'm very happy it's taken me as far as having entire infrastructure (almost) of forkable/reproducible defined in a single config file: ;)
<southerntofu>but i don't feel confident to write an entire ecosystem of selfhosting recipes in such a fragile "language"
<southerntofu>proper type checking would make me so happy
<nckx>So you came to Scheme.
<southerntofu>not exactly just yet, i've been learning rust for a while and i've never been happier with a programming language's ecosystem
<southerntofu>but i've always been tempted to learn lisp and more functional programming, and guix project is really tempting technically and politicaly
<southerntofu>i'm just afraid of the tradeoff of spending months learning new tech instead of focusing on the problems i'm trying to solve :)
<southerntofu>which is why i'm asking if other folks (or a group) are on the same page as me, because if it's a collective effort i'll be drawn in for sure
<southerntofu>that is, if i can contribute some sysadmin concerns, plus feedback from actual end-users (including myself but not only) and learn guile along the way that'd be a good approach for me, but i don't feel like starting alone a tentacular project in an ecossytem i have no clue about, if that makes sense to you
<Telc[m]>I program in rust primarily
<Telc[m]>but i dont see a great benefit to it for guix configuration as far as a syntax
<Telc[m]>type checking would be nice to be sure
<screwdupgrub>nckx: Nope there were bunch of entries. And the last was Guix. But I'll need to run efibootmgr again
<nckx>southerntofu: I think you should write a medium-sized e-mail to help-guix at, in addition to asking on IRC. Mail lends itself better to it IMO.
<nckx>screwdupgrub: You can run it now.
<southerntofu>Telc[m]: rust for guix no i don't see the point (though guix for rust makes sense), but writing high level sysadmin abstractions in rust would make perfect sense, in fact we had a discussion about this on newsboard which then moved to a bugtracker:
<nckx>I'm just curious how many entries you have, and if ‘no space left’ is a reasonable complaint.
*nckx → 😴
<southerntofu>nckx: thanks, i probably will at some point, i'll probably try to polish my drafts and proof-of-concept (ansible based) before i write to the mailing list though :)
<nckx>IRC is great for fast answers, not broad reach.
<nckx>Good night Guix o/
<southerntofu>good night :)
<screwdupgrub>me go zzz too
<roptat>southerntofu, if you want to have a look at some examples, I have my system config here:
<roptat>it's all my systems, including desktop and servers
<screwdupgrub>sneek later tell nckx that I get same "Could not prepare Boot variable: No space left on device" will try with live usb later
<sneek>Will do.
<southerntofu>thank you very much roptat i'm very interested indeed, in case you have more examples at hand :)
<roptat>there's also the infrastructure of guix itself, at
<roptat>that includes the website, the build farm and workers
<southerntofu>so it's one file per machine? (yours is clearer with a README)
<roptat>each top-level .scm file in maintenance/hydra is a machine
<roptat>berlin is the one that runs the build farm's head and website
<roptat>also, we have "guix deploy" that work in a similar manner to ansible, but better (of course :p), although it can only deploy guix machines
<roptat>basically, it builds the machines locally, connects to them, send the updated store items and reconfigure
<southerntofu>yes i was really curious about guix deploy but then i realized unless i was using guix system there was no notion of "services" to be managed
<roptat>it builds the machine content*
<roptat>what do you mean by "services"?
<southerntofu>from what i read (maybe it has changed since then) guix only manages services via shepherd so using guix on foreign distros is limited to basic package management from my understanding
<southerntofu>like i can't setup and enable service for nginx (for example) on a distro that is not guix system?
<roptat>oh yes, but you can always create VMs and use giux deploy to other machines that are guix system from a foreign distro
<roptat>no indeed, not on your local machine at least
<southerntofu>yes but i don't have a lot of resources for VMs and such.. i administer only two of those and they're on debian because of reasons (i didn't want to setup a system noone else knows to maintain)
<roptat>the way it manages nginx for instance is by generating a full operating system that has the configuration you declare, so everything is managed by it, reproducible, etc
<roptat>and nothing messes with your configuration
<southerntofu>yes, i really like that :)
<roptat>if they're all yours, you can do whatever you want, but if they belong to a collective, then I agree that you'd have some work to do to convince other people to try out another OS :)
<southerntofu>so i took a quick look at the two repos, it's interesting but incredibly verbose.. for example DNS setup could use higher level abstractions
<roptat>right, everything is very low-level when it comes to declaring services
<southerntofu>does the guile language/ecosystem play well with building higher-level abstractions?
<roptat>it's just a matter of designing a good higher-level abstraction
<Telc[m]>there is also the ability to deploy into containers
<Telc[m]>that looks like its in good shape
<Telc[m]>has there been any work on syscall restrictions?
<roptat>right, but that's only for guix system
<roptat>not that I've heard of recently
<southerntofu>well then i'm very interested in your feedback on the high-level abstractions i've started to document/implement ->
<southerntofu>if we could do that kind of stuff with guix i'd be thrilled
<Telc[m]>thats kind of my concern with shepherd overall
<southerntofu>(that's the README for the project but each role has its own README with documented interface)
<Telc[m]>is that systemd has a lot of nice things baked in now
<roptat>I don't know much about ansible, so I don't know how much I can understand
<Telc[m]>including syscall restrictions in the service description
<southerntofu>roptat: the READMEs are only about semantic configuration interface, there should not be anything specific to ansible in there and it should be possible to implement the same semantics in any language or configuration format
<l00p>Hello, I'd like to submit wallpaper art for GuixSD. Where can I apply?
<roptat>hi l00p! I think you could send them to guix-devel at
<southerntofu>(ah damn i broke links when i moved roles into a submodule)
<roptat>I think I understand what you want to do
<roptat>so you'd have a server that has the basic declaration, but services would be handled differently than they are in guix
<roptat>you have a field of services that "enable" some extensions that you can add to your declaration (.common, webserver, etc)
<roptat>and then you can configure those extensions
<roptat>I see for instance in the webserver, you have a list of vhosts, and each of them can have a specific template
<southerntofu>exactly, each service has its own configuration namespace and the server has some top-level config (like hostname)
<roptat>at this point, I this is very similar to what guix does (or at least could do very easily)
<roptat>like, we would have a static-web-service-type, a zola-service-type, etc
<roptat>that would extend the nginx service type
<roptat>it's kinda reversed in terms of semantics though
<southerntofu>then each service can dynamically call other services, like for a typical web setup, webserver service calls tls service to setup TLS certificate (letsencrypt), which in turn calls webserver service to setup a vhost without TLS for answering ACME challenges
<southerntofu>roptat: yes exactly
<roptat>we have a similar mechanism with "extensions", although it doesn't work well for let's encrypt ^^'
<southerntofu>except semantically i believe a user wants to configure a webserver that behaves in a certain way (profile), not have to look up for the precise type of web server they need to invoke :)
<southerntofu>(but it's essentially the same)
<southerntofu>what's wrong with letsencrypt on your "extension" ?
*vagrantc watches guile compile on armhf ...
*jlicht grabs the pitchforks
*southerntofu spills coffee in the chan
<roptat>well, if you configure a service to use tls, nginx will fail to start when the certificate is not yet present, so it cannot answer the first challenge :/
<roptat>otherwise, it works great
<southerntofu>roptat: that's why i use a bootstrapping step in tls service, calling webserver without TLS :D
<roptat>oh ok, I do the same with guix ^^
<southerntofu>(though i plan to implement DNS challenges at some point, when i have time to take care of nameserver service)
<roptat>the only difference I see is that the webserver service does not extend the let's encrypt service
<roptat>and I think that's by design, because the certificate could come from another source
<southerntofu>roptat: also what's different semantically/functionally in "my" approach is that a profile extends a service, but is agnostic to the implementation (it's a well-known interface and nothing more).. for example webserver can be fully implemented with apache instead of nginx without changing a single line of config theoretically
<roptat>oh, interesting
<roptat>that's exactly what I wanted to do with "extension points" I introduced in the guix home manager
<southerntofu>roptat: yes but webserver service can accept an argument configuring the source for TLS certificates (could be an internal CA for all we care :))
<southerntofu>roptat: i'm not familiar with that, can you link me to some docs? :)
<roptat>so instead of extending nginx, you'd extend a "webserver" extension point, and any service that listens on that point is extended with the value
<roptat>not sure I have any, let me check ^^'
<southerntofu>(in fact i plan to support arbitrary CA in most services so we can automate their deployment in a CI pipeline to run functional integration tests)
<jlicht>I recall you writing a long email abouth this roptat
<roptat>I think we could implement all that with extension points and wrapping guix service into something a bit less generic, that generates them
<roptat>ah that's right!
<roptat>southerntofu, that's the second half of this email:
<southerntofu>yes yes yes i love that roptat thanks you made my night :D
<southerntofu>i mean we're basically reinventing the wheel.. well-known specified configuration across programs
<southerntofu>but it's a foundational element most sysadmins i know don't care about because they value their handcraft (which i appreciate in another sense, but does not encourage learning/customization/reproducibility/forkability)
*southerntofu gonna read the whole thread :)
<southerntofu>personally i'm up for calling that an "interface", i find it more clear than "extension point" :)
<l00p>thanks roptat, I sent my submission to the guix-devel group
<southerntofu>thanks l00p can't wait to see that :)
<roptat>southerntofu, whatever works :)
<roptat>I'm not too attached to the name I came up with ^^
<southerntofu>anyway thanks a lot folks for taking me down this rabbithole :)
<southerntofu>good night
<roptat>vagrantc, it's kind of a nice feeling to look at an armhf machine build stuff for a long time
<roptat>taking its time to build each step
<roptat>very soothing compared to the speed at which new lines are added on more powerful architectures :)
<southerntofu>(also please let me know if there's a group/chan specific to high-level semantic sysadmin, or maybe we should make one?)
<roptat>we try to keep everything in one place
<roptat>so there's only this chan, and mailing lists