IRC channel logs


back to list of logs

<jab>anyone using prosody for their own im?
<jab>I've got prosody running, but can't seem to login because it's not using the lets encrypt cert...
<jab>detrout: how are you setting up certs?
<detrout>jab, i am even connected to this irc channel via the xmpp gateway biboumi
<jab>detrout: oh...That's cool!
<detrout>letsencrypt and entering the paths in my config file
<jab>detrout: can you send me some code?
<detrout>technically i'm using debian and just lurking on guix because it's interesting, so I migth not be able to help with some guix specific details
<rekado>i used prosody in the past, but certs were always messy
<rekado>I ended up copying them and chown-ing them so that the prosody user can access them.
<jab>rekado: the website mentions that the easiest way to use the let's encrypt certs is to "prosodyctl --root cert import /etc/letsencrypt/live"
<jab>though it looks like that needs to happen everytime the cert is updated...
<detrout>Here's my prosody virtual host block though (with domain names changed)
<iskarian>rekado, for some reason your patch is downloading as html for me...
<jab>detrout: thanks.
<detrout>and yes prosody needs to be reloaded when the cert changes
<iskarian>I was able to copy-paste it though.
<jab>detrout: how do you let prosody use those certs? those certs are only accessible by the root user, which prosody doesn't run as...
<detrout>My cron currently has a block like this certbot -q renew --deploy-hook "systemctl reload prosody; systemctl reload dovecot; start-stop-daemon --quiet --oknodo --stop --signal 10 --pidfile /var/run/mumble-server/ ; systemctl restart exim4"
<jab>detrout: gotcha. thanks!
<singpolyma>Yeah, I don't know why prosody recommends that import command. But you do need to reload the TLS module somehow when the cert is renewed. I use admin_telnet and a shell one-liner
<singpolyma>If you want a package with prosody in it and everything set up for you Snikket is nice
<jab>well that's interesting...
<jab>I'm having a hard time creating a new admin user for prosody on guix system.
<jab>error Unable to write to accounts storage ('/var/lib/prosody/gnucode%2eme/accounts/jbranso.dat~: Permission denied') for user:
<jab>I'm logged in as the root user.
<jab>maybe I cannot create accounts when prosody is running...
<jab>nope...still not working.
<detrout>Is the database in guix's store? or is it in read/write space
<jab>I don't actually know...
<detrout>i'd cd to the directory and see if I could create files in it
<jab>data-path is "/var/lib/prosody"
<detrout>that sound like it's out of the store.
<guixy>Hi guix! Just sent Jupyter-service patch! bug#50708
<jab>detrout: I might be running into issues because I'm trying to create <same username> and <same username>
<detrout>I think prosody tracks the full jid for account names
<detrout>At least the account databases are stored by virtual host "prosody/gnucode%2eme/accounts"
<jab>detrout: yup.
<jab>I think part of the problem is /prosody/gnucode%2eme/ is owned by the user "smtpd"
<jab>that's probably causing issues.
<detrout>yeah that sounds pretty likely
<jab>frick...I may have broke my letsencrypt settings by accidentally changing the owner of the /var/lib/letsencrypt directory...
<jab>and now ssh-ing into my server is super slow all of a sudden...
<iskarian>rekado, so I've learned some things! Apparently with pep 517 there *is* no direct installation. You *must* build a wheel and then install the wheel. PEP 517 also requires build isolation by default, which is why neither pip nor build see local dependencies!
<iskarian>You can disable build isolation with "pip --no-build-isolation" or "build --no-isolation"
<iskarian>With the latter I'm getting inscrutable "ZIP does not support timestamps before 1980" errors
<iskarian>Ah, (setenv "SOURCE_DATE_EPOCH" "315532800") solves that (taken from another package)
<iskarian>rekado: this works:
<iskarian>I think the python-build-system really needs to be updated
<oriansj>minor bug report for meld on non-guixsd systems: guix environment --ad-hoc meld gtksourceview --fallback always fails to display a valid diff but guix environment --ad-hoc meld gtksourceview@3.24.10 --fallback works just fine. So the current package definition needs to be revised to correct the current issue.
<attila_lendvai>my idris2 packaging works, but not yet ready for submission:
<attila_lendvai>it bootstraps everything all the way down from GHC
<oriansj>attila_lendvai: it'll certainly be much more exciting once we finally properly bootstrap GHC
<attila_lendvai>oriansj, or a better haskell compiler comes to the scene that is easier to bootstrap. i heard that bootstrapping GHC was not much cared for, and it's a nontrivial endeavor.
*attila_lendvai is thinking of Csaba Hruska's Grin compiler
<oriansj>attila_lendvai: I guess you haven't heard of blynn compiler yet
<attila_lendvai>oriansj, no, thanks for the pointer! i'm not too deep into type systems, more of a lisper (for now)
<oriansj>fair. I'm much more of a bootstrapper than a lisper. So if you want to know the dirty details of bootstrapping I am more than happy to help people learn more ^_^
<singpolyma>Can someone help me understand everything that `guix pull` does? I think of it an analogous to `apt update` to pull definitions for new packages, but it obviously is a lot more heavyweight
<iskarian>attila_lendvai, impressive!
<raingloom>singpolyma: can't explain everything, but the gist of it is that it downloads guix and compiles all its modules. it doesn't just download a database file.
<iskarian>however, instead of setting LD_LIBRARY_PATH, can you compile it such that the RUNPATH is set correctly?
<singpolyma>raingloom: And there's no way to have it compile on-demand like guile normally would, right?
<raingloom>attila_lendvai: damn, did you build idris2 with idris1? is that even a good idea to do on CI? it takes like 12 gigs of RAM or something.
<attila_lendvai>oriansj, i have learned a lot about bootstrapping through a tiny self-hosting lisp:
<singpolyma>If I guix archive --import an archive with a version of guix and dependencies in it, would that be enough to make guix pull take less time?
<raingloom>singpolyma: well, you could work from a local checkout. but guix needs to evaluate all package modules when it searches for a package by name, so there is not much point in delaying that work.
<singpolyma>raingloom: hmm, well in my context (CI build for specific package) I don't think any package lookups by name will happen
<attila_lendvai>raingloom, i haven't seen any excessive memory usage. my laptop has 16 gigs, -6 for the browser, and i was never getting close to the limit. IIRC i began this on a 8gig laptop, and i didn't even notice
<raingloom>dang. maybe Idris1 had some improvements while I wasn't looking. well, i'm hoping to see idris2 in guix soon. :3
<attila_lendvai>iskarian, i lack knowledge to make sense of "compile it such that the RUNPATH is set correctly". can you point me to an nice example in the guix repo?
*attila_lendvai websearches RUNPATH
<attila_lendvai>raingloom, i'm also considering setting up the use of bootstrap shortcuts (use the git-comitted build artifacts to produce an executable)
***Xenguy_ is now known as Xenguy
*attila_lendvai has finished reading
<singpolyma>Hmm, it seems this fix is not in even the debian unstable version of guix yet. Given the way that guix is packaged for debian, I don't think there's a way to update the daemon is there?
<iskarian>attila_lendvai, that seems like a pretty good overview
<iskarian>in Guix, we have modified our ld to (essentially) add a RUNPATH entry for every library linked
<attila_lendvai>iskarian, not sure it'll be easy, because idris emits scheme, and it is then compiled with chez
<iskarian>Was chez already in Guix?
<attila_lendvai>iskarian, yes
<iskarian>Then it *should* be doing something like that, and if it's not, that should be fixed
<iskarian>until then... LD_LIBRARY_PATH is probably fine
<attila_lendvai>iskarian, also, AFAIU idris is using these through some dynamic FFI mechanism... not sure how that relates. (although, grep -r dlopen and dlsym comes back empty)
<iskarian>Do you know what the actual compilation commands look like? (the ones that emit an executable?)
<iskarian>If not, I'll actually compile it and take a look... sometime in the next couple weeks, haha
<attila_lendvai>iskarian, i'm having a hard time finding that out. probably i should delve into learning some idris now, because i can't even read the code really... :)
<attila_lendvai>i can't even find its FFI in the codebase... maybe i should just sleep... :)
*attila_lendvai goes to sleep... o/
<jab>hey guix people! I now have my prosody server serving my XMPP account Feel free to say hello!
<jab>I have not entirely fixed the buggy certificate issue. it works for now, but I'm not certain if it will work after a restart. Or reboot. Or in a few months when the letsencrypt certificate gets updated.
<jab>well that's super weird...
<jab>sudo herd status prosody says that prosody is stopped...but I am still talking to myself...
<jab>this feels like a bug.
<jab>sudo herd stop prosody
<jab>sudo herd status prosody --> stopped.
<jab>sudo prosodyctl status --> it is still running.
<michzappa>hey jab, I was reading your posts about running a dovecot server on Guix System, how's that going?
***califax- is now known as califax
<apteryx>where is the bit about adding some code to the channels.sch file for pulling only to a guix having substitutes documented? I can't seem to find it
<apteryx>ah, found it. info '(guix) Channels with Substitutes'
<iskarian>sneek, later tell atilla_lendvai: the nixpkgs idris2 doesn't do a bootstrap chain; it uses the git checkout and chez to bootstrap. am I missing something as to why the bootstrap chain is necessary?
<sneek>Got it.
<apteryx>sneek: later tell ytc the x200 performance is quite good; it has 8 GiB of memory and an SSD. The only place it's not really at home is for video playback
<sneek>Got it.
<apteryx>sneek: later tell ytc haven't compared Guix System on it to other distributions though
<sneek>Got it.
<iskarian>heh, I really need to switch my x220 over to linux... windows updates are starting to bring it to a standstill
<raghavgururajan>sneek, later tell nckx: Thanks so much for the info. :)
<sneek>Will do.
<raghavgururajan>apteryx: You are using x200?
<nckx>Morning, Guix!
<sneek>Welcome back nckx, you have 1 message!
<sneek>nckx, raghavgururajan says: Thanks so much for the info. :)
<nckx>Sorry for the infodump more like. Forgot to mention that I use Coreboot now, but it should work identically with both Lenovo and Libreboot firmwares too.
<civodul>Hello Guix!
<sundbry>Hello #guix :D
<nckx>Hi civodul & sundbry!
<qzdlns[m]>morning guix!
<civodul>mbakke: one of my favorite workarounds: :-)
<civodul>so, core-updates-frozen is still not in a great shape
<jbv1[m]> Hi guix! I try to make modifications to the julia-build-system on my local checkout of the guix repository but somehow when I do ./pre-inst-env guix build julia-uri (for example) the last version of julia-build-system.scm does not seem to be loaded? Any clue what I am doing wrong?
<attila_lendvai>iskarian, ouch! the binary generated by chez is a #!/path/chez --script followed by some binary data; i.e. it's not an elf binary with RUNPATH
<sneek>attila_lendvai, you have 1 message!
<sneek>attila_lendvai, iskarian says: the nixpkgs idris2 doesn't do a bootstrap chain; it uses the git checkout and chez to bootstrap. am I missing something as to why the bootstrap chain is necessary?
<attila_lendvai>sneek, it's not necessary, but i want to keep it alive as an option. that's why it's not ready for submission: i want to be able to build both paths and compare the end results.
*makx should figure out how to get hacking on guix properly; except for the excessive compilation wait times for aarch64 I am pretty sold on it (being a scheme person i prefer guix over nix ;))
<civodul>makx: :-)
<civodul>jbv1[m]: hi! could it be that your modifications have no effect for some reason?
<civodul>if you could share a diff perhaps we can try and guess
<mbakke>civodul: incredible workaround :-) thanks for the quick fixes
<mbakke>since there is a final full-rebuild coming up, I wonder if we should just patch Guile?
<mbakke>there is also
<jbv1[m]>oups actually it was loading the last version
<civodul>mbakke: oh right; maybe it's worth patching it, yes
<civodul>no strong opinion, either way is fine i think
<jlicht>civodul: the minus-start fix made my eyes bleed
<jlicht>in a good way ;)
<civodul>i liked that "ah ha!" moment when i thought about that trick
<gyps>Dear all, im just trying to install guix and so far it went really smooth. Great!
<gyps>But now I'm trying to set up my emacs/EXWM config. For that I need to compile pdftools and this is done using gcc.
<gyps>Somehow if I install the gcc-toolchain package the gcc complains "ld: cannot find crt1.o: ..."
<gyps>If I use package gcc-bootstrap this error does not appear. Any Idea what could be wrong here?
<jlicht>gyps: unrelated to the actual issue you ran into, but we should have an emacs-pdf-tools package that already takes care of compiling epdfinfo
<gyps>OK. I'll try that package. But somehow strange that gcc-toolchain doens't work.
<apteryx>eh, 'guix pull' took 3h 17m on an NXP i.MX6 quad core (ARM)
<apteryx>I'm trying to set it up a TS7970 board as an offload armhf machine; got Guix installed on it, but so far offloading returns: 'guix offload: error: remote command 'guix repl -t machine' failed with status 127' so probably I have to add Guix to the PATH
<gyps>OK. The emacs-pdf-tools package works.
<gyps>One general question: For each emacs package there seems to exist a corresponding package in guix. Is it preferrable to use the guix package rather than the ELPA packages?
***wielaard is now known as mjw
<singpolyma>gyps: up to your preference, but I would say yes
<ss2>would someone like to have a quick look into this?
<ss2>Could it be that I'm getting this after poluting my profiles with packages that are not from the default channel?
<civodul>i ended up posting yesterday's blog post on HN:
<civodul>feel free to "upvote" and whatever it is people do on HN :-)
<Soheil[m]>How to configure and replace a graphics driver in Guix System?
<dportnrj[m]>hello. drivers in xorg-configuration:
<Soheil[m]>dportnrj: Thanks
<abcdw>Hi guix!)
<bavier[m]>hello guix!
<abcdw>bavier[m]: o/
***darosior1 is now known as darosior
<nckx>Hi bavier[m] & abcdw.
<bavier[m]>I've been pretty quite here lately. Hope everyone's been doing well.
<abcdw>Doing a stream on guix deploy in 25 minutes, everyone is welcome to join)
<vivien>Hi, the "guetting started" page on the manual ( points to the Guix Cookbook (, but the link is dead.
<civodul>abcdw: oh nice!
<civodul>vivien: weird, that must be something with htmlxref.cnf in doc/build.scm
<abcdw>civodul: today will try to stream to PeerTube too)
<roptat>vivien, civodul, I think I saw a patch that was related to this
<civodul>that'd be great
<vivien>Also, I’m sure a lot of people will be drawn to guix by abcdw, if the Getting Started page has a bad link they won’t be pleased ^^
*jonsger-laptop found another on c-u-f :(
<vivien>I’m viewing the stream with MPV: mpv --ytdl-format=95
<vivien>The peertube stream does not seem to work though, I hear your voice but the screen is black
<singpolyma>Is there any way to convince guix buld to fetch substitutes in parallel?
<roptat>singpolyma, -M<n>
<roptat>(also known as --max-jobs, by default set to 1)
<roptat>note that it will also let guix *build* multiple derivations at the same time
<singpolyma>Ok. How are -M and -c different? -c is just for threading in scheme land and -M gives me concurrency across actual packages?
<roptat>-M is for the number of derivations that are built at the same time, -c sets the number of cores that can run in each derivation
<roptat>*can be used
<singpolyma>Will -c use make -j and similar for gnu-build-system?
<roptat>by default -c is set to the actual number of cores your CPU has
<roptat>although, some build systems disregard that value
<roptat>I think rust will always build all online cores (unless we apply similar workaround than LFS), and some build-systems will always build with a single core, like java
<lilyp>is there any way of making ant-built java packages work with maven or should I just ignore them?
<roptat>you can replace the install phase with a call to install-from-pom
<roptat>you might need to add parent poms to the propagated-inputs too
<roptat>(and runtime dependencies too...)
<roptat>you can find an example in java-asm@6
<lilyp>I have a feeling that install-from-pom will fail in some scenarios, though
<lilyp>e.g. log4j
<lilyp>What I'd really like is the ability to point at a jar already built with Guix and generate a pom that tells Maven "Don't worry, the adults are here."
<Soheil[m]>Whats wrong here?
<Soheil[m]>"invalid field specifier"
<lilyp>Well, I don't know which field specifier is invalid, but if that indentation is correct then you need to start counting brackets :)
<Soheil[m]>roptat: Can you help? 😁
<lilyp>yet another reminder that append list is evil and cons* is good
<roptat>Soheil[m], probably parenthesis issue again? :)
<roptat>looks like the services field is closed just before the modify-services form
<roptat>so remove one closing parenthesis at the end of line 13, and put it on line 18 instead
<roptat>which reminds me, I should work on that "invalid specifier" patch of mine
<roptat>Soheil[m], I don't know which editor you're using, but any good editor should highlight the corresponding parenthesis when you're on an opening or closing parenthesis, that should help you find where groups don't match what you expect
*jonsger-laptop filed
<jonsger-laptop>do we support XFS as root file system?
<abcdw>vivien: Oops, it's sad that peertube didn't show the video. When I was testing it today it was ok :/ Yep, mpv with youtube-dl works quite well, use it too)
<Soheil[m]><roptat> "so remove one closing parenthesi..." <- did not work :/
<roptat>Soheil[m], ah there's another issue: remove another closing parenthesis on line 13, and add one on line 10
<roptat>again, you should be able to find that yourself
<niko>i don't know who invited litharge here but it could take care of those broken client, see /msg litharge help ccycle
<Soheil[m]>roptat: Thank You. Anyway, because you are the best at this, I asked 😉
<abcdw>vivien: Checked the recording on PeerTube, seems it's ok, video is here.
<vivien>Maybe it’s a problem with webkit
<abcdw>vivien: maybe. Have a nice evening everyone. o/
<nckx>jonsger-laptop: No, I don't think so.
<lispmacs>hi, I don't know much about rust, but was wanting to package
<sneek>lispmacs, you have 3 messages!
<sneek>lispmacs, maximed says:
<sneek>lispmacs, maximed says: Actually, that's not always correct, let me send a new version
<sneek>lispmacs, maximed says:
<lispmacs>but "guix import cargo gemserv" does not find anything
<lispmacs>I meant, "guix import crate gemserv"
<lispmacs>do I need to get gemserv published on, or is there something I do not understand about the package name, or something else...?
<roptat>how can guix find this package if it's not published on
<roptat>it can't get any info otherwise, just with the name :)
<lispmacs>roptat: I guess I'm trying to understand: I can run "cargo build" and build everything automatically, so apparently all dependencies are on
<lispmacs>so why isn't the package itself on just an oversite of the author...?
<roptat>oh, but "guix import" doesn't look at the local directory, it just tries to find the package you give it on
<roptat>maybe it has a different name?
<lispmacs>roptat: that is my question, how would I know what the correct name is
<roptat>dunno, maybe ask the author?
<lispmacs>it appears that gemserv is the package name according to the provide Cargo.toml file
<lispmacs>I guess the author must not have published it to for some reason
<roptat>I wonder if we could import from a Cargo.toml directly
<roptat>I don't know much about rust either
<pinoaffe>hi guix, in which module should a 3d-printing related package (prusa-slicer) go?
<pinoaffe>or should I create a new module along the lines of (gnu packages 3d)?
<roptat>maybe (gnu packages 3dprinting)?
<lispmacs>roptat: sounds like I need to talk to the guy who uploads those 87 guix rust packages every month
<lispmacs>I mean, package definitions
<lispmacs>maybe I'll check with the author, get clarification on if he was going to publish it to
<lispmacs>I noticed on you have to enable JavaScript to even use the site
<lispmacs>maybe I can find him/her on the tilde IRC chat
<lilyp>pinoaffe: I already pushed prusa-slicer earlier today :/
<lilyp>It's in engineering.scm
<pinoaffe>lilyp: lol, nice
<roptat>well, we can always move the package if necessary, but we can keep it there for now :)
<pinoaffe>lilyp: I finally got my attempt at packaging prusa-slicer to work today :P
<lilyp>You can amend the existing recipe if you think I flubbed, but the other one has been waiting for a few weeks (almost two months) by the time I started reviewing ^^"
<lilyp>I'd particularly be interested in how you tackled libigl
<pinoaffe>your package appears to be more clean than mine, so I'll just happily use yours
<the_tubular> New `--max-depth' option for `guix graph'
<the_tubular>More guix progress :D
<pinoaffe>lilyp: I disabled graphics cuz I couldn't get those to work, and I didn't debundle many of the dependencies
<lilyp>Fair enough, that's what one would typically expect from an initial working version
<lilyp>I really ought to buy a graphics card that doesn't hate me
<podiki[m]>has anyone used phoronix-test-suite on guix?
<lilyp>I recently saw it in the wishlist, but no
<Soheil[m]>Can anyone solve the problem? "invalid field specifier"
<lilyp>Try this:
<podiki[m]>I'm trying their tarball in a guix environment, but didn't seem to find openssl (trying the kernel build test), despite including it in the guix environment
<lilyp>hmm, do they use pkg-config or some other weird magic to find it?
<Soheil[m]>lilyp: Thanks for help
<Soheil[m]>/etc/config.scm:49:5: error: (xorg-configuration (keyboard-layout keyboard-layout) (modules (cons* nvidia-driver %default-xorg-modules)) (server (transform xorg-server)) (drivers (quote ("nvidia"))) (service virtlog-service-type) (service libvirt-service-type (libvirt-configuration (unix-sock-group "libvirt")))): invalid field specifier
<lilyp>one missing bracket after drivers
<lilyp>on the closing side
<podiki[m]>Soheil: emacs with smartparens or something similar will be very helpful
<Soheil[m]>podiki: 👍️ Thanks
<podiki[m]>no one should suffer needlessly finding parens :)
<Soheil[m]>But this is really strange!
<podiki[m]>meanwhile the actual phoronix kernel test "quit with non-zero exit status" and no logs I can find.....very helpful
<Noisytoot>I use paredit
<lilyp>Real programmers use electric-pair-mode.
<Noisytoot>Real programmers use ed-mode
<lilyp>I'd like to see the ed script, that balances parens.
<Noisytoot>maybe paredit or electric-pair-mode can run in
<lilyp>I doubt it
<podiki[m]>some other phoronix tests seem to work, not sure what is wrong
<nckx>Soheil[m]: I can recommend ‘rainbow-delimiters’ if you like your editor to point things out, but not magically *do* (too) much.
<podiki[m]>that's a good one to have too
<lilyp>podiki[m]: Looking at the test suite it appears it's searching for several versions?
<podiki[m]>I'm not sure it needs it for the actual compile test, and it downloads the kernel source just fine (what I assume it needs it for?), but just guessing
<podiki[m]>I can't seem to get any verbose or debug output, so I can't tell what phoronix is trying to do that is failing
<podiki[m]>for anyone curious, i'm doing `guix environment --ad-hoc php bc bison flex openssl` with the downloaded test suite, running `./phoronix-test-suite benchmark build-linux-kernel`
<lilyp>Try patching ob-cache/test-profiles/pts/openssl-1.11.0/downloads.xml
<lilyp>Or adding your own openssl-1.12.0/downloads.xml
<podiki[m]>patching with what exactly?
<lilyp>I'd say 1.1.1j or 1.1.1l, which are present in Guix (the former regularly, the latter grafted)
***soheil_ is now known as soheil
<podiki[m]>doesn't seem to make a difference. i wish there was some useful output, just fails on the actual running of the test without output
<lilyp>Is there a verbosity switch somewhere?
<podiki[m]>not that I've found, nor debug :-/
<podiki[m]>there's a log that has nothing either
<lilyp>there's a field $debug_mode in the pts_client
<lilyp>not sure if changing it to true unconditionally helps or if the problem is elsewhere
<podiki[m]>ah, more useful in ~/.phoronix-test-suite/installed-tests/pts/build-linux-kernel-1.12.0 working directory
<podiki[m]>can run the thing directly and get output
<podiki[m]>okay, think that is working, added libelf and elfutils to environment
<podiki[m]>I wonder how it would make sense to have this in guix, maybe using guix environment to run tests to pull in dependencies that way? (rather than a package with all the many deps it has)
<jonsger-laptop>can Guix boot from an XFS root partition?
<dstolfa>i don't see why not
<podiki[m]>Or maybe phoronix should support using guix environment to get dependencies, like it can for other distros i think
<nckx><nckx> jonsger-laptop: No, I don't think so.
<dstolfa>nckx: hm, why can't guix boot from xfs?
<dstolfa>isn't it just in the kernel?
<nckx>dstolfa: No, Guix needs to support each root file system type, e.g.,
<dstolfa>oh i see. that's slightly unfortunate :(
<nckx>Don't overestimate how hard that is; I added JFS support on a lark because some random asked about it in here.
<nckx>dstolfa: Why? It's a loss less code than pulling in the entire (huge) blkid stack that does exactly the same in C.
<nckx>Well worth the bit of duplication I'd say.
<dstolfa>nckx: i don't disagree, i was just hoping that it wasn't necessary :)
*nckx skips away to read about the XFS superblock
<nckx>(It's been asked more than twice now, so its time has probably come.)
<jab>nckx you added in JFS support just because someone asked for it?
<jab>bcachefs ? :)
<jab>also friends, I've got an email account and jabber account on! Only dkimsign is not working for my email account yet...
<nckx>jab: Yeah. Never used it myself before or after testing it.
<nckx>bcachefs, I use myself.
<jab>nckx: how hard is it to do that on guix? use bcachefs?
*jonsger-laptop would jump in as XFS beta tester :)
<nckx>The nckx answer would be ‘oh, not hard at all! great fun!’ and then slowly remember all the weird hoops I actually jumped through & weird code I had to write, over the course of the next half hour.
<nckx>So let me think.
<nckx>Well, you'll be running the bcachefs kernel fork, for one, which *can* be combined with the Linux-Libre processes but it's work I've chosen not to do. And you need to make sure your /boot is not-bcachefs, because GRUB still lacks support, and a separate /boot isn't yet supported natively by Guix. But apart from that I honesly think I've upstreamed everything needed to boot Guix on it.
<nckx>jonsger-laptop: Thanks! I'm going to end up adding it simply because I don't want to have to rebase a huge patch I have queued up that touches all of this fs stuff 😉
<drakonis>jab: oho i'm going to copy your configs
<drakonis>i want to send emails
<nckx>jab: Congrats, by the way.
<nckx>jab: Are you stuck with dkimsign? I assume you're talking about the OpenSMTPd filter.
<nckx>filter out proc-exec "/run/current-system/profile/libexec/opensmtpd/filter-dkimsign -d -s 2018 -c relaxed/relaxed -k /etc/guix/mail/dkimproxy.key" user nobody group nogroup
<jab>the prosody (XMPP server) does not work with my letsencrypt certs out of the box...
<jonsger-laptop>nckx: so I using an EFI partition (FAT32) + XFS inside LUKS? will this be feasible?
<jonsger-laptop>otherwise I'll just go back to ext4 (or something different)
<nckx>Once the XFS procedures are written it should be, yes.
<nckx>Then LUKS doesn't matter.
<jab>You have to start said server, then "sudo su; guix package -i prosody; GUIX_PROFILE="$HOME/.guix-extra-profiles/vala/vala" . "$GUIX_PROFILE/etc/profile"; prosodyctl --root cert import /etc/letsencrypt/live; prosodyctl restart;"
<jab>also it seems like sudo herd stop prosody; doesn't actually stop prosody, which is kind of weird.
<the_tubular>Damn, close to 200 commits, what happened ?
<jab>nckx: thanks for the command. I'll give that a try. The only problem with filter-dkimsign is that it only works for 1 domain name. Not too.
***soheil_ is now known as soheil
<nckx>Ooh, nice
<jab>nckx thanks. I've been working on this off and on for way too long.
<nckx>jab: Ah, that's quite possible; my needs are eminently modest.
<nckx>I'm… surprised, but have no reason to disbelieve you.
<drakonis>the_tubular: things happen
<drakonis>activity is good and 1.4.0 approaches
*the_tubular wonders what the hell is trytond
<jab>I'm not certain why the author doesn't want to support multiple domains, but eh, I'm not complaining. If he doesn't wanna offer it, that's ok. I'm not paying him...yet.
<the_tubular>There's going to be a lot of guix home question I think
<nckx>jab: Well, my understanding was the same as Martijn's here <>
<the_tubular>When 1.4.0 releases
<jab>nckx: can you translate that technical jargon for me? Is he saying it "technically does support" multiple domain names via the same signing key?
<nckx>He's saying, and I think this applies to you as well, ‘multiple domains don't mean what you think they mean’. Are you aware of any service providers or spam filters that will actually punish you for sending mail from signed with a key?
<nckx>I'm not, but I haven't been deep into e-mail practices for quite some time.
<nckx>Me agreeing with Martijn doesn't imply either of us is right. :)
<drakonis>the_tubular: tryton is some erp thing?
<drakonis>guix home will be so good though
*nckx AFK, then XFS. o/
<jab>nckx: gotcha. That's what I thought he meant. :) I'll have to try it out and see!
<jab>and to answer your question, I do not know of any service providers or spam filters that will punish you for doing that. I had just assumed that they would. :)
<nckx>jab: Think about it this way: do you have two rDNS's for your two domains? Probably not, or you wouldn't be running a single smtpd. Same thing. Hope that's clear, cuz I really have to run now.
<jab>drakonis: are you using guix home yet?
<drakonis>not right now no
<jab>I haven't been able to set it up properly yet..
<drakonis>i'm going to set guix up again on this machine tonight
<jab>best of luck! Send me some code when you've got it done!
<drakonis>will do
<drakonis>did it get merged into the main branch?
<jab>I don't believe it has been merged yet.
<jab>There was a recent discussion about it on the mailing list...Apparently they are trying to figure out how to merge/intermingle system services with home services. Apparently a fetch-mail home service will start automatically even if there is no internet connection, which is kind of odd.
<jab>Also will home services/system services have the same code? It seems like it is hard for them to share code.
<drakonis>it'll be an interesting journey
<drakonis>nix's home-manager had an explicit separation between user and system services
<drakonis>since it lived on a separate repository, so there was a lot of code duplication
<jab>hmmm. I did not know that.
<drakonis>it is entirely defined by its circumstances
<lilyp>I'd personally say there's room to make configuration the same, but the implementation would still need to adapt
<drakonis>guix home can avoid all of those issues
<iskarian>hello all :)
<lilyp>drakonis: I'm really not sure about that "all" bit given the different locations at least, but let's just say "most" to be on the sure side
<iskarian>hmm, I've been wondering... are all end-user applications which might need SSL certs supposed to set a search path for e.g. SSL_CERT_DIR, or is that expected to be set by something else?
<drakonis>most issues, yeah.
<maximed>iskarian: I think so, yes?
<maximed>FWIW, adding SSL_CERT_DIR to the search paths of every certificate package (nss-certs and le-certs) would have the same effect I think?
<maximed>the same effect, with less work, less opportunities to forget adding it?
<iskarian>Yeah, adding a SSL_CERT_DIR search path to nearly every network-enabled application seems like excessive duplication IMO
<iskarian>but I've encountered this twice in the past week, having to manually set it
<maximed>iskarian: It isn't problematic for things like GUILE_LOAD_PATH, which only has a few consumers: the different versions of Guile
<maximed>but for SSL_CERT_DIR, it might make sense to invert things
<iskarian>The odd thing is I'm running on Guix System, which provides an /etc/ssl/certs directory
<iskarian>yet I'm finding some Guix applications still have to have SSL_CERT_DIR=/etc/ssl/certs
<iskarian>in order to see it.
<maximed>which applications are these?
<iskarian>hmm. one was pianobar, another is the pirate-get submission i'm testing