<gabber>zacchae[m]: i don't think they will blacklist you just because -- but you might end up telling people (through another channel than email) that they should check their spam folders. that being said i think Guix has the tools and services at hand to let you set everything up (see 12.9.12 in the manual), but usually an "email server" setups consist of more than just the MTA.
<juliana[m]>what would the complications be to renaming the Guix git's default branch?
<juliana[m]>...what does cat disruptor 9000 mean why is it flagging my messages
<gabber>juliana[m]: about the git main branch name: my guess is that services and infrastructure sometimes in and sometimes explicitly refer to that branch and it'd be a bunch of work and possibly disruption to all
<zacchae[m]>gabber: Thanks. I thought I might be able to get away with exim configured with maildir, but I don't really know what I'm doing :) if you know of some guide for a self-hosted email server ssimilar to what might work on guix, I would greatly appriciate it.
<zacchae[m]>squeaktoy: I was goinig to try and view it with gnus in emacs (via maildir I think?)
<frog>zacchae[m]: you can just follow any guide for setting up an email server. guix doesn't have any fancy interface for configuring mail transfer agents yet, so the configuration is entered as one giant file-like object in the system config. (the only tricky part is that you may need to use mixed-text-file to insert the full path of a program into a config file.) I think you will be fine with only a mail transfer agent if you run emacs
<frog>on the server itself. or maybe download the maildir with rsync.
<frog>if you set up the extra email security features properly, set up dns properly, and wait a couple weeks, your email won't get rejected from gmail anymore. (don't test with an email name that you plan to use for real. your real domain is fine, but not the name part.) I set up these security features in addition: dkim, dmarc, smtp tls reporting, and spf.
<juliana[m]>google and microsoft use heuristic spam filters based on the age of the mail server. you might be fine at first, and you might be fine for a while, but the chances of staying fine forever are slim
<juliana[m]>i saw a graphic once demonstrating that you have to scale up the amount of email your server sends at a defined but exponential rate to avoid being labeled a spam server
<juliana[m]>so in order not to get send to the spam folder you functionally have to - wait for it - send spam
<juliana[m]>ah woops sorry forgot editing on matrix sends another message to irc
<frog>i cant find anything similar to what you described, but google does say that if your end goal is to send lots of email then you need to progressively increase it. its probably not that bad.
<apteryx>janneke: ah, for the %environment-options unbound error, a workaround is to use 'environment' instead of shell, e.g.: guix time-machine --commit=1bf55a485028be4eca79300f914b8e2d12433e43 -- environment --ad-hoc hello -- hello
<zacchae[m]><frog> "on the server itself. or maybe..." <- I sync my entire home directory with syncthing, so I think maildir will just automaticaly work on remote devices
<zacchae[m]><frog> "if you set up the extra email..." <- That's a lot of extra features... I'm hoping that filtering out any incomming not addressed to my domain is enough to not get rightfully blacklisted
<zacchae[m]><juliana[m]> "i saw a graphic once demonstrati..." <- I don't care if people's spam filter blocks me so long as it isn't justified. At that point, it's my friend's fault for using a shitty email service
<frog>the features i mentioned relate to outgoing mail, not incoming mail. google requires at least spf or dkim now or they will just reject your email entirely. iirc, dkim is the only one of the four i mentioned that actually requires software to set up. the rest are just dns records.
<zacchae[m]>frog: Neat. Spf seems straightforward enough. Hopefully that and filtering out incomming mail addressed to external domains is enough
<mobius_>trying to learn pkg mgmt w guix. i'm reading through the manual and can't find how to remove config files when i remove a pkg
<frog>if you created it manually, you have to delete it manually. if it was created automatically through a system service or guix-home service, it will be removed automatically when you remove the service. (although remain in /gnu/store until garbage collected)
<zacchae[m]>mobius_: if the package generates the config files, then there is nothing guix can do. Program config directories are not consistent. I think you would have to delete them manually
<mobius_>oh okay, thank you. at least they're all pretty easy to find
<mobius_>okay so would there be any reason to add additional channels besides the official? from what i can tell and from how i want to use my system, it would be no
<zacchae[m]>mobius_: The problem is that guix only manages the store, and config files tend to change over the usage of a package. The real solution is to manage your config files with "guix home", and remove the config files from your home declaration when you remove the package (or create a service that adds the package and config files).
<mobius_>thank you zacchae, give me a moment to digest what you're saying
<zacchae[m]>it is very rarely necessary to add additional channels. More likely that you will add a "-L /path/to/local/guix" to guix commands to use some defs in a local repo
<mobius_>okay i found "invoking guix-home". it's 13.4 of the manual
<mobius_>curious if there's like a quick reference for just day to day use? the manual is very well written, but it's very indepth and easy to get overwhelmed
<zacchae[m]>Unfortunately, the official document like that is the guix cookbook, and it is quite sparse. I can recommend the system crafters youtube channel, but otherwise, this irc is the best I have found
<mobius_>ah yes, i found system crafters. very cool videos
<mobius_>so in theory i could pull source code of the main packages I use, compile it myself on a remote server, then set that up to be my own custom channel? like just for the experience and knowledge
<mobius_>okay, so i'm going to subscribe to guix-devel and try to connect with someone to help me write a quick ref beginner's guide on everyday use. if anyone wants to help, maybe keep an eye out there
<mobius_>something else i'm curious about. i'm reading a bit through the shepherd manual to try to understand how to manage services, and i see references to systemd. does guix use both shepherd and systemd, or are those for people using guix pkgmgmt on top of another system?
<zacchae[m]>guix ships with some systemd service units to work on foreign distros, but I don't think you can do any systemd things through guix
<juliana[m]>okay, apparently when shepherd talks about "systemd-style services" it's referring to how incoming connections are handled
<juliana[m]>so i don't think it can use systemd service files
<juliana[m]>i thought that was a real weird thing to have lol
<mobius_>yeah, i was a little confused by that lol, but your explanation clarifies
<mobius_>i have to get going, thanks for the help everyone!
<itd>apteryx: I can offer 'guix time-machine --commit=7670efefe4fb4aca12cb19ea5d89ff37c48e3ea6 -- build hello'
<fries>hey, when sending a patch series, is using --compose with git-send-email supported. i tried that when i sent my series and i tried putting a body and either it doesn't see the summary email or it teams.scm script just errors out.
<fries>yeah, i sent a patch series to an existing bug after juliana reviewed my patch. i split up my big patch into 5 patches.
<fries>anyways for my series i just pressed reply on my email client on the last patch as a sudo-cover letter
<fries>i mean if its getting sent to the bug address, it should be fine
<ronniedroid18>I am giving gnu/guix a try on a debian system. I am having difficulties defining services. I have made a `(ronnie modules fish)' module which exports 'my-home-fish-service-type` and `my-home-fish-configuration`, but guix says `my-home-fish-service-type` is unbound variable, and asking me if I have used the module `(ronnie modules fish)`. I have
<ronniedroid18>used the module inside my `(home home-configuration)` module (the file which contains my home-environment.
<ronniedroid18>my files are inside `~/dotfiles/ronnie` and `~/dotfiles/ronnie/modules`, I run guix home with `-L ~/dotfiles`
<iyzsong>ronniedroid18: there may be some syntax errors in your module, i'd try 'cd ~/dotfiles; guile -L . ronnie/modules/fish.scm' first.
<iyzsong>i think 'guix' report less errors than 'guile', it sometimes hide the issues..
<Kabouik_>So I freed some more space and it guix package -u finally worked nckx. I think it ate more than 10GB though, and took several hours to complete. What can I rm now to free the space the upgrade took? guix gc after a package delete-generations I guess, but maybe also ~/.cache/guix?
<pjals_fox>sudo guix system delete-generations && guix home delete-generations && guix package delete-generations && rm -rf ~/.cache/guix && guix gc
<pjals_fox>that assumes you want to say bye-bye to rollbacking to previous generations
<Kabouik_>I don't use guix home or guix system on that device, so I had cleared everything I could already apparently!
<nckx>Hey Kabouik_. Weird that my client didn't ping me above. It's not unusual for 'guix upgrade' (or its synonym 'guix package -u') to eat >10GB. What was implausible was that 'guix pull' alone would use 11GB in a manner that's returned to the system on failure. There are a handful of huge packages (think webkit*) that use tonnes of temporary space, but they shouldn't be part of 'guix pull's closure.
<ekaitz>oh that could be too! cdo256 you could try in a container somehow
<Kabouik_>It's entirely possible that I wrongly reported the issue as following a `guix pull` when in fact it was following `guix package -u` nckx, since I usually run both in a row. I'm sorry if that was not accurate and made you wonder what was the issue.
<Kabouik_>I definitely need to find a way to free some space on that phone for the future. Already moved all big documents/media on a SD (with the threat of the SD dying out of nowhere, like most my SD cards did).
<cdo256>Removing the GUILE_LOAD_PATH from my home config fixed it. But it doesn't make sense that GUILE_LOAD_PATH should affect a --pure shell does it? Does that mean that somehow guix shell --pure isn't as pure as intended? Or is it okay in this case?
<egnun>Hey #guix, I'm trying to install GuixSD from the iso image. I've written the image to an USB stick followed all the steps.
<egnun>Now quite at the end the install process always fails, with an error like: "Can't write to /mnt/ probably no space left"
<egnun>It says, that it wants to write about 4GB of data, but only about 800 MB (the size of the image) would available.
<cdo256>Hmm, Yeah that's not nearly enough for how much needs to be written to /gnu/store/
<cdo256>Mine's currently using up 115GB (though I haven't run gc in a while). I'm not sure what the reccomended root drive size is for guix but it'll be quite a bit more than you would use for OS's which don't use a functional package manager.
<egnun>115? You know guix gc works quite well these days? ;-)
<cdo256>My last drive failed without me knowing after I ran an aggressive guix gc, so my system couldn't boot and I couldn't roll-back. Took me weeks to get back to normal. So now I live with the paranoia and hoard outdated outputs in case it happens again.
<egnun>This is a good reminder, that on Guix I probably should start doing backups of / again.
<nckx>It… er… well… it's probably obvious what it does.
<nckx>And your system can be recreated from your system configuration (created by the installer as /etc/config.scm) and any other files it references, although I tend to back up all of /etc just to be safe.
<nckx>Users can install extra packages using ‘guix install’ etc. Root can do this, too, but here root is just another user, not ‘the system’.
<nckx>You can consider the system profile as a base layer, then each user has their own profile in which they can install whatever they want.
<nckx>That base layer is entirely defined by the /etc/config.scm you just created with help from the installer. If you sent it me, I could ‘guix system build’ or even ‘guix system vm’ that file and get something very close to your system, assuming I recreate your partition layout etc.
<podiki[m]>ci isn't showing new derivations for several days now, any updates?
<nckx>egnun: Although, in practice, you might still end up creating/editing other stuff in /etc because the abstractions aren't complete or perfect yet.
<nckx>Anyway, consider /gnu to be like /usr, and unlikely to be space/time-efficient to back up.
<nckx>podiki[m]: I just noticed that I'm still building email@example.com from source. I didn't look into it after restarting Cuirass. I think you know more about it than I do.
<egnun>> If you sent it me, I could ‘guix system build’ or even ‘guix system vm’ that file and get something very close to your system,
<egnun>Yes, this is actually where I want to go. I'm currently just testing stuff in a VM and after that, I want to extract the config.sc(a)m file to actual hardware, where I have Guix currently running on a foreign distribution.
<egnun>Because I was told, that I could do a $ guix init to replace the running OS with GuixSD.
<egnun>Which sounds quite nice, if it acutally works :-D
<nckx>It works, but it doesn't actively hunt down & delete the previous OS. You'll very likely end up with a working Guix System with plenty of old junk lying around (I've installed a few machines this way), with a small chance that some left-over configuration file still takes effect. If you're anything like me, this'll bug you and you'll perform a clean installation to feel clean again. But it's an option.
<RavenJoad>nckx: Did you have a chance to look at my apcupsd stuff?
<ulfvonbelow>how would one go about getting the PID in the root pid namespace of a process given its PID within another namespace and the PID in the root pid namespace of another process that is in the same PID namespace?
<ulfvonbelow>that is, process P1 has PID1 in the root namespace, process P2 has PID2 in the PID namespace of P1, what is the pid of P2 in the root namespace?
<apteryx>seems guix time-machine is prone to hanging up; e.g. commits circa August 2021 such as 8ef38cd1bf7ec17b8d1bc1c0bcb42ac30ac30406
<janneke>apteryx: it thought it would be easy to get ab0ede51c041927a1c35535aec3504f84d7a9751 (2019) to work, because i traveled there for quite some time...
<ulfvonbelow>if we ever set up a team to maintain 'guix time-machine' compatibility, I propose we name it 'time-cops'
<viaken>I'm not sure I understand the use case difference between grub-efi-bootloader and grub-efi-removable-bootloader. I get that one installs to the default bootloader location and the other Guix-specific, but what are they *for*?
<RavenJoad>viaken: For your system to boot with EFI, you need an EFI program that loads the initrd after UEFI/BIOS and grub run. both bootloader types install the EFI program to the boot device so your OS loads. The difference between them is where the EFI program is put.
<RavenJoad>grub-efi-bootloader should be preferred, because it allows you to have multiple OS's EFI programs to make switching the booted OS easier. grub-efi-removable-bootloader is for some motherboards which "forget" the location of those EFI programs custom locations, so removable puts them in the spec-defined location.
<juliana[m]>oh so removable is what i needed to not have to do weird sorcery to get my replacement laptop to recognize the OS on the SSD i transfered from my previous, identical laptop
<juliana[m]>(Weird sorcery being using ventoy to boot then running a system reconfigure)