<the_tubular>I'm still having the guix upgrade issue, am I the only one ? <AwesomeAdam54321>the_tubular: I have the guix upgrade problem as well, guix package -u upgrades packages even though they're already upgraded <AwesomeAdam54321>the_tubular: emacs, git, git:send-email, icecat, icedove, irssi, lagrange, magic-wormhole, minetest and wine <djeis>So... I'm trying to set up guix system on a server and it's failing to find my sata disks during the boot process. /dev/sda and such aren't getting created. <djeis>They do show up in the guix I'm using to do the install- I used that to format them etc. <djeis>But when I actually try to boot it can't mount the root fs and some investigation shows those files haven't been created. <djeis>Does anyone have an idea for why the drives aren't showing up? I don't think I'm doing anything particularly weird- I am trying to use md raid, if that matters. <rekado>AwesomeAdam54321, the_tubular is there a bug report about this? <the_tubular>I don't know, I def should make one but been very busy. <the_tubular>No clue how that would work, but I'd like to test something. <jgart>maybe what guix needs is a custom build system for racket to avoid the complexities of raco ***dgcampea-2 is now known as dgcampea
<ajarara>Np. Gonna try seeing what git --exec-path is during the test phase in the build: it's fine when I run tests manually in a container, following the guide in the info pages. <ajarara>yep. Echoing $PATH during the run shows the build dir though. <ajarara>unless the path I see is not the path git has, somehow? I feel like that's not possible but not sure what else could it be. <Ribby>Hey, I got the 64 bit bootload working, thanks to the proper flash command. <Ribby>Apparently, the latest release is basically the stable release with revisions and 64 bit. Is there more than what meets the eye? <ajarara>(if anyone has any pointers, sneek/tag me, will check the logs after work tomorrow) <Ribby>somehow, cannot connect to the guix 64 server ***dgcampea-2 is now known as dgcampea
<sughosha>Hi everyone, I have configured my guix home for the first time. However, I still have `~/.guix-profile`. Should I, or will I be able to, get rid of it? When I do `guix package --list-profiles`, it doesn't show my `~/.guix-home`. Is it normal? <mange>I believe that's normal. It looks like Guix home installs an extra profile in ~/.guix-home/profile, which is entirely independent of ~/.guix-profile. <sughosha>Hi guys, is there a way to exit from `guix repl`? <roptat>(that's the usual keybinding to exit from readline stuff, and it works even when you didn't load readline support in guile) <sughosha>balbi: Cool, thanks! I was going to system monitor and then end process until now.. *unmatched-paren just realized how easy adding a zig-build-system would be <unmatched-paren>because zig doesn't have a package manager, we wouldn't need to do any weird stuff <rictjo>hello everyone. I am getting a glibc build error for julia when trying to add packages via the julia package manager. I'm not skilled enough in guix to solve it. <efraim>the_tubular: should be doable, I'd toss it in the activation script of the service you're working on <efraim>rictjo: can you share the build error on paste.debian.net <rictjo>the error I am seeing is `GLIBC_2.33' not found (required by /gnu/store/...-julia-1.6.3/bin/../lib/julia/libstdc++.so.6 <rictjo>ERROR: "/tmp/jl_viF1iG/Registry.toml": No such file <efraim>the_tubular: for a quick example take a look at openntpd-service-actvation in gnu/services/networking.scm <the_tubular>Here's my goal, I found a few malware samples that refused to detonate when certain conditions are met <efraim>rictjo: I would suggest adding p7zip to the manifest in generic_julia. It looks like p7zip is linked against glibc-2.31 and julia against 2.33 and somewhere along the way it's causing problems <gnoo>hello, i'm getting Unrecognized image file format (gdk-pixbuf-error-quark) from packages like sway <jpoiret>gnoo: does `grep svg ~/.guix-profile/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache` give you anything? <jpoiret>and does `echo $GDK_PIXBUF_MODULE_FILE` give you the aforementioned file? <gnoo>yes, it gives /home/me/.config/guix/current/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache <jpoiret>can you confirm (by using less or something) that the file contains a duplicated entry for libpixbufloader-svg.so? <gnoo>yes, there are two of them <rictjo>efraim: thank you for your recommendation. This resolved the issue <jpoiret>gnoo: this might be the issue but I wonder how that could happen <gnoo>jpoiret: `guix build gdk-pixbuf' tries to apply some grafts, should i do that and then guix package -u? <jpoiret>building or using `package -u` will give you the same output (thankfully :p) <jpoiret>and the .cache file is generated by a profile hook <jpoiret>can you copy the loaders.cache file somewhere else out of the store, remove the duplicated entries (maybe just this one but there might be others), then set GDK_PIXBUF_MODULE_FILE to the path of that file and try launching sway from that same terminal <jpoiret>sway needs to see the new env variable <gnoo>jpoiret: i tested in another application and it works! <jpoiret>so that's your workaround, now we need to know why that ends up the way it is <jpoiret>did you guix pull && guix package -u recently? <gnoo>yes, i did that yesterday <abrenon>I'm trying to compile a Markdown into a PDF with pandoc <abrenon>I have it installed in my user profile, and everything works great <abrenon>but I'm also trying to write a manifest of what is actually needed, so that I can come back to that even if my profile changes in the future <abrenon>if I enter the shell with --pure, it can no longer find the image files included in the document which have an accent in their name (UTF-8 encoding) <abrenon>any idea what package might be missing ? <abrenon>my locale is set normally, yes (to fr_FR, by the way) <abrenon>would that change in a --pure environment ? <jpoiret>inside the pure shell, I personally don't have it set <abrenon>makes sense, I don't want a "pure" shell to depend on some accidental variable set outside of it <jpoiret>i think it's one of these env variables that could be kept by default, like DISPLAY or TERM <abrenon>ok, but then how am I supposed to tell the manifest: "oh, and by the way don't forget to set locale to fr_FR" ? <abrenon>not sure, there's a big implicit here, that my document is supposed to be compiled on a french-localized environment <jpoiret>you can, however, do `guix shell --pure -E ^LANG\$ -m manifest.scm` <abrenon>and I'm honestly grateful to guix for pointing that out <abrenon>but… ? then I won't control its value and if someday my locale shifts to pt_BR, then what is going to happen ? <abrenon>surely there is a way to define this variable one way or another, isn't there ? <jpoiret>you could write a bash script that sets up your shell, and do `guix shell -m manifest.scm -- setup.sh` <abrenon>isn't there a way to make a fake empty package that only defines the variable ? <jpoiret>eh, you can only do search paths though <jpoiret>there's definitely something to be done here i guess <abrenon>that's incredible, why would guix pay so much attention to setting the proper variables when building profiles, including search paths, if environment variables weren't part of it ? <jpoiret>well, guix mostly cares about files, it's still a package manager <jpoiret>the whole "setting up your environment" thing came with guix system <jpoiret>search-paths are here as a compatibility shim with how guix stores packages seperately in the store <jpoiret>gnoo: I don't have the duplicated entry <jpoiret>can you try to find out which package combination does that? i'd say by using a manifest and somehow bisecting it <abrenon>now I find that localectl list-locales is empty, and localectl status says my system locale is non-available <jpoiret>(you can use guix shell -m .... -- bash -c "grep librsvg $$GDK_PIXBUF_MODULE_FILE") <jpoiret>abrenon: erm, localectl is a gnome thing, you don't have to worry about that <abrenon>great, I didn't like it when I discovered all those *ctl stuff were on my guix system too <jpoiret>LANG is the authoritative source, since it's what libc uses when a program uses `setlocale()` <abrenon>I interestingly find that my files are found with LANG=en_US.UTF-8, or en_GB, or fr_FR, but not pt_BR <abrenon>I thought all that mattered was for the locale to be UTF-8 <abrenon>now I'm full of doubt and marvel at all the knowledge I'm still missing <jpoiret>that's because glibc-utf8-locales only has de_DE, el_GR, en_US, fr_FR, tr_TR <jpoiret>and it might be that that's the one being used in the profile <abrenon>also, why would those languages be treated separately ? is that a matter of additional special characters they add ? <jpoiret>a locale specifies how you would like to be presented information, not the encoding (that's the UTF-8 part) <jpoiret>well, a locale contains both rather :p <jpoiret>so if i set my locale to fr_FR, i'll get messages in french from libc, euros instead of dollars, celsius instead of farenheits, etc... <abrenon>yeah, that was the understanding of locale I had <abrenon>I don't see why that should have any influence on the ability of pandoc to find files in a directory in my all-UTF-8 system <gnoo>jpoiret: hmm, is there a way to reinstall it system-wide? maybe it'll get the correct version now? <jpoiret>well, many programming languages don't have UTF-8 strings by default which is annoying <jpoiret>gnoo: there's no correct version for it, it's always locally built based on what's in your profile <abrenon>"oh, you don't care whether the name of the month before or after the date number ? then how do you expect that I can find this file which you gave me the exact path of, encoded in UTF-8, on a system where the files all have their names written in UTF-8 ??? that's an impossible task !!" <jpoiret>pranavats: as well as on other distros, meaning not that great <abrenon>jpoiret: yeah I suppose it would be something like that, but the resulting behaviour is really poor and counterintuitive <jpoiret>abrenon: the default locale if none is specified is C, which doesn't have UTF-8 encoding <gnoo>jpoiret: is there a way to rebuilt it on a controlled enviroment? <gnoo>or maybe not so controlled enviroment <abrenon>yeah, but it's a bad decision to make it restrict things <abrenon>if you have no idea what the encoding is, then a byte is a byte, and as long as it matches you shouldn't care <jpoiret>i don't think it will change, but you can try to figure out if changing the packages in the profile end up generating a different loaders.cache with the command I gave above <jpoiret>just use a manifest and try removing packages until there's only one occurence <abrenon>there are already forbidden chars due to the file system, I can understand that C doesn't want to go accross null bytes but apart from that it should be all the more fine <gnoo>jpoiret: also, after that update, aspell complains: Error: No word lists can be found for the language "en_US". <gnoo>something has gone wrong and i don't know what :P <jpoiret>abrenon: i don't know how/why filesystem interfaces would be encoding-specific, but there may be reasons <jpoiret>gnoo: do you have anything in $DICPATH? <jpoiret>i'm not sure that hunspell dictionnaries are pulled in by default <avalenn>abrenon: IIRC the only forbidden characters in POSIX-compliant FS are "/" and nul. <jpoiret>i think the issue starts when you have case-insensitive filesystems (looking at you ntfs) <jpoiret>you'd have to somehow know which character is the uppercase of which according to the locale <abrenon>shouldn't that be implemented in the driver of said filesystem ? <abrenon>avalenn: which is expected, I'm ready to accept some hard-coded universal limits <abrenon>but thinking that some binary compiled code, not even interpreted, supposed to efficiently handle data, is going to stop at each character to wonder if it has the right to come across it depending on the value of an env variable is simply more than I can bear <jpoiret>that's one of the possible issues when you have standards that are 30 years old <abrenon>I am over thirty years old and I don't make a fuss if you ask me to compare two words written in my alphabet, even if they're from a language I don't understand <pranavats>jpoiret: I can find one debian bug report on update-grub not creating `/boot/grub/.background_cache.png`. Are you aware of any other issues with Luks2 support in Grub2? <pranavats>jpoiret: Would you suggest sticking with Luks1 for now? <jpoiret>yes, currently, you need to have a separate unencrypted /boot partition <jpoiret>if you can manage to do that, then LUKS2 will work without any issues, otherwise it won't work because of a bug in GRUB2 <jpoiret>remember to use PBKDF2 as your pbkdf parameter, not argon2 and friends <pranavats>pbkdf2 because argon2 has time and memory cost for opening? <pranavats>jpoiret: It turns out I had been using Luks2 all this while. We had a conversation earlier about recovering a corrupt luks header. <jpoiret>because argon2 is not supported by GRUB2 yet <jpoiret>oh, right. So did you manage to recover the header then? <pranavats>Still it seems the header was gone completely because of a decade old bug in debian installer. <pranavats>I couldn't recover it. I tried using photorec, radare2 to search for luks header bytes, manually browsing hexdumps. <jpoiret>i hope we don't have the same bug :) <pranavats>Yeah. My best bet was recovering a backup of my header from the flash drives it was once copied to (and then deleted). <pranavats>jpoiret: I was using the default value of pbkdf for Luks2 with Grub2 before. I guess that would have been argon2. And it was sort of working. <jpoiret>pranavats: I don't think so, the latest GRUB really doesn't support it <jpoiret>there are preliminary patches in the GRUB ML but they haven't been merged yet afaik <jpoiret>it's possible that other distros patch their own cryptsetup to change the default pbkdf <tschilptschilp23>Hi guix! Does anybody know how to 'tweak' php memory limits and add php-modules (ideally from the guix config). My app complains about a too low preconfigured memory-limit for php and missing OPcache and redis-modules. I actually do see a php-fpm.conf.default in the store, which seems to define memory-limit. I also see a 'opcache.so' in a '[STORE-php-location]/lib/php/extensions/no-debug-[...]/' directory, but have no clue how to <mange>It looks like there's an option to provide a "file" in the in the php-fpm-service-type, which becomes the php-fpm.conf file, but that completely overrides the generation of that config file (i.e. you don't get anything from the default file). <mange>I'm not sure if there's a way to add things to the existing file, but at least overriding it means that you can find some way of doing what you want, I guess? <tschilptschilp23>mange: nice, thank you -- I totally overread that information! The last line of this files also says to respect contents of 'php-fpm.d', so maybe I can find a way to place something in there... <phf-1>When clicking on ̀Specifications' in `(see Specifications in Cuirass).' <phf-1>sneek tell later mothacehe in the blog post it's written `(name "flat")' in the Cuirass doc, it's written: `name: The specification name as a Scheme symbol.' then should it be not `(name 'flat)' ? <sneek>later, phf-1 says: mothacehe in the blog post it's written `(name "flat")' in the Cuirass doc, it's written: `name: The specification name as a Scheme symbol.' then should it be not `(name 'flat)' ? <jpoiret>phf-1: I think it's "later tell" rather than "tell later" <phf-1>sneek later tell mothacehe in the blog post it's written `(name "flat")' in the Cuirass doc, it's written: `name: The specification name as a Scheme symbol.' then should it be not `(name 'flat)' ? <gnoo>jpoiret: there are two directories in DICPATH and both of them don't exist <gnoo>both of these dosen't exists: /home/me/.guix-profile/share/hunspell:/run/current-system/profile/share/hunspell <jpoiret>yeah, it seems you don't have any dictionaries installed <gnoo>it was working before that guix pull tho <jpoiret>aspell uses hunspell dictionnaries right? <gnoo>i'll install it again just in case <jpoiret>installing really won't change anything <jpoiret>if it's already installed you'll get the same profile <jpoiret>compared to usual package managers on guix reinstalling doesn't have any side effects <gnoo>yup, i have aspell-dict-en installed <gnoo>guix package -I | grep dict-en => aspell-dict-en 2020.12.07-0 out /gnu/store/v90ifhzvln0p61i6xpadjj6qvjqvr4sb-aspell-dict-en-2020.12.07-0 <gnoo>ok, i think this is the source of problem: <gnoo>type -p -a guix gives ~/.config/guix/current/bin/guix and /run/current-system/profile/bin/guix <gnoo>both of them are different binaries <gnoo>.config/guix/current/bin/guix: symbolic link to /gnu/store/d4sl3ci6vgyikjywxywwp3z1jp23cjy2-guix-command <jpoiret>`which guix` gives you ~/.config/guix/current/bin/guix, right? <jpoiret>as long as that's the case, everything's good <gnoo>yeah, the default is from ~/.config/guix/current/bin/guix <jpoiret>the former is the guix from `guix pull`, that's installed in the pull profile at ~/.config/guix/current/ <gnoo>also, i'm getting some incompatible byte-compile errors lemme check the errors right now <jpoiret>the latter is the default one available from the system, which is almost always outdated <gnoo>;;; In procedure load-thunk-from-memory: incompatible bytecode version <gnoo>;;; WARNING: loading compiled file /home/me/.config/guix/current/lib/guile/3.0/site-ccache/guix/build/utils.go failed: <gnoo>this is while starting shepeherd user <jpoiret>if so you'll need to reconfigure your guix home as well <jpoiret>so you have an .scm file from it right? <gnoo>with: { sleep 2 ; shepherd ; } & disown <gnoo>yes, in ~/.config/shepherd/init.d/ <jpoiret>you need to update your package, and force guile to recompile the compiled go file for it <jpoiret>guile was updated from 3.0.7 to 3.0.8 recently <gnoo>ok, i do have guile-3.0.8 installed already <gnoo>how do i force it to recompile? there's no compiled files in ~/.config/shepeherd <gnoo>yeah, there are, should i just rm -rf ~/.cache/guile/ccache ? <jpoiret>you can, it may slow up the startup of your guile files the next time you load them <gnoo>ok, i removed it, will restart shepherd again <gnoo>it's still giving me those warnings, i'll restart now <gnoo>nope, it's still there. but the errors are from .config/guix/current/lib/guile not from ~/.cache/guile/ so maybe it's something different? <jpoiret>is .config/guix/current/bin before .guix-profile/bin in PATH? <ceephax>is it possible to run ./pre-inst-env guix install <package>, as when i try do that, the package installs but i cant run or find it? <gnoo>yes, the first entry is .config/guix/current/bin (it's actually repeated 3 times) <gnoo>/home/me/.config/guix/current/bin:/home/me/.config/guix/current/bin:/home/me/.config/guix/current/bin:/home/me/.config/guix/current/sbin: <gnoo>and again once after this <gnoo>/home/me/.local/bin:/home/me/bin:/run/setuid-programs:/home/me/.config/guix/current/bin:/home/me/.guix-profile/bin:/home/me/.guix-profile/sbin:/run/current-system/profile/bin:/run/current-system/profile/sbin <gnoo>this is how i set my PATH: export PATH="$HOME/.local/bin:$HOME/bin:$PATH" \n . "$guix_profile/etc/profile" \n . "another_guix_profile" <gnoo>although that another profile is not working for some reason... <gnoo>aaaa now even the sound is not working <gnoo>ok, i think something has seriously went wrong <jpoiret>this code sets your path before you source /etc/profile, right? <jpoiret>are you perchance setting your PATH or sourcing /etc/profile in your bashrc? <gnoo>i don't manually source /etc/profile, but this is the first line in ~/.bash_profile <gnoo>this is my ~/.profile which is sourced on the first line of ~/.bash_profile with [ -f $HOME/.profile ] && . $HOME/.profile : http://ix.io/3Qvg <jpoiret>where are you sourcing .config/guix/current/etc/profile then? <gnoo>i'm only sourcing ~/.guix_profile, isn't that the default one that is used? <gnoo>~/.guix_profile/etc/profile <jpoiret>.config/guix/current/ is the guix pull profile <jpoiret>so you also need to activate that one <jpoiret>but your PATH has it so I was wondering how it ended up there <jpoiret>tbh, to set up the default profiles i just do `. /etc/profile` on guix system <jpoiret>it has everything necessary to set it up <gnoo>it looks like /etc/profile sets that up <gnoo>for profile in "$HOME/.guix-profile" "$HOME/.config/guix/current" <gnoo>and /etc/profile is read by bash when invoked as a login shell <gnoo>ok, so i don't need to manually . .guix_profile/etc/profile either, maybe that's the cause of some of those duplications <gnoo>btw, is your guix /gnu/store/q2v8wsdwb8mm1ywfbr55iwhx4chaw4s2-guix-command ? <jpoiret>hmmmm, i forgot zsh has its own startup files, and so only my .zprofile is executed, so i need to source /etc/profile in it... <jpoiret>my guix will be different to yours since I don't think we pulled with the same commit <gnoo>well i pulled it again so it should be the same, i think <jpoiret>i pulled this morning so it might have changed <gnoo>yeah, okay, is there a way to know which is the current commit i pulled from? <gnoo>so that should be alright <gnoo>i'll pull, package -u and then reconfigure the whole system, right now even audio doesn't work <jpoiret>if so, you can try running `pactl info` to get some info about the pulseaudio server <gnoo>no, i use alsa; the error is: <gnoo>ALSA lib dlmisc.c:339:(snd_dlobj_cache_get0) Cannot open shared library /gnu/store/1adbrln88chyshjsswcqfbr9cg9li25k-alsa-plugins-1.2.2-pulseaudio/lib/alsa-lib/libasound_module_pcm_pulse.so (/gnu/store/1adbrln88chyshjsswcqfbr9cg9li25k-alsa-plugins-1.2.2-pulseaudio/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory) <jpoiret>which program is responsible for the error? <gnoo>yeah, it doesn't exists. this error was from mpv but i can't use mpd either <jpoiret>for things like audio, you sometimes have to upgrade system and packages in tandem <gnoo>i did guix gc today in hopes of solving the gtk error so maybe that's the problem <jpoiret>alsa-plugins contains, well, plugins so there aren't any explicit references that would keep them in the store <jpoiret>i'm not sure what would install it though, or why ALSA would still try to access the old one <gnoo>should i give you my `guix package -I' ? <gnoo>well i'll try after reconfiguring the system, right now it's running guix package -u <jpoiret>also, after updating packages, the best way to test is to log-out and log-in again <jpoiret>since you have to source the profiles again <gnoo>nope, `env | grep -i alsa' gives nothing <ceephax>i realised that after a ./pre-inst-env guix install <package>, i can spin an ad-hoc environment up to use the new packages ./pre-inst-env guix environment --ad-hoc <package> <mbakke>ceephax: you don't need to install it first <jpoiret>i never try to do things that modify my system and profiles with ./pre-inst-env (modulo testing guix system changes on real hardware) <jpoiret>./pre-inst-env guix shell is the way to go, even guix build to simply inspect the built packages <ceephax>do you mean like: guix shell -D guix help2man git direnv strace less --pure" ? <ceephax>this is what i was doing before running the ./pre-isnt-env <jpoiret>i see you've effectively banned gm from your vocab :p hi nckx <nckx>I might use the shorter ‘yo’ next time, but please remember at all times that it is canonically short for ‘yodelahiti’. *nckx misses the kaiserschmarrn already. <abrenon>I'll never see the "yo" greeting the same anymore <nckx>Meanwhilst, back at the topic (sorry): is anyone using bcachefs with Guix System? Anyone? <nckx>It's still experimental. <jpoiret>i'm already living on the edge using btrfs <nckx>You won't get it with our linux-libre, which is why I'm asking. I might maintain a linux-libre-with-bcachefs channel if there's interest, to counter the Nix dominance in bcachefs early adoption :) <nckx>But since I myself don't use linux-libre, a number of users >0 would be nice. <nckx>(I don't share others' optimism that it will be mainlined any time soon, although I admire them for it.) <nckx>With that, I shall recede into trying to build Android, which is the most harrowing case study in ‘practical software freedom’ I've seen so far. Tschüss! <jpoiret>i've abandoned that prospect myself, i need a beefier machine ***dgcampea-2 is now known as dgcampea
<nckx>jpoiret: Ah, oh dear. I was gifted a telephone and the only reason I accepted was that I assumed I could build my own image. <jpoiret>if it's anything that's not a pinephone or librem, you'll struggle with proprietary bits <jpoiret>and building your own image usually requires 100G+ of disk space, 16G RAM minimum, etc... <nckx>Sadly the gift was merely a few €100, not verymany €100. <jpoiret>android being free software is a pipe dream <nckx>So it seems. Still, my laptop meets those criteria, and I'm not giving up just yet, but off-topic it once again is. Unless you got anywhere close using Guix? (I'm wasting some RAM on a Trisquel VM which would be nice not to waste on a Trisquel VM.) <jpoiret>no, unfortunately. I think roptat has some of the build tools on a channel, but maybe not all <acrow>Strong work on android Mr. Lepiller. Nice! <apteryx>lilyp: do you mind if I submit your XDG_DATA_DIRS webkitgtk patch upstream? <apteryx>nckx: out of curiosity, what's the reason you don't use linux-libre? <apteryx>firmware-related, minimalism, something else? <apteryx>lilyp: also, if you don't mind I submit your webkitgtk patch upstream, do you want add your real name, and CC your email address to keep you in the loop? ***sobkas_ is now known as sobkas
<gnoo>i reconfigured the whole system as well as updated the packages <gnoo>but i still get this error: ALSA lib dlmisc.c:339:(snd_dlobj_cache_get0) Cannot open shared library /gnu/store/1adbrln88chyshjsswcqfbr9cg9li25k-alsa-plugins-1.2.2-pulseaudio/lib/alsa-lib/libasound_module_pcm_pulse.so (/gnu/store/1adbrln88chyshjsswcqfbr9cg9li25k-alsa-plugins-1.2.2-pulseaudio/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory) <apteryx>nckx: haha, such optimism, I see you haven't been burnt by Android yet; is the bootloader unlocked, as a start? <gnoo>i installed alsa-plugins 1.2.2 and it's in /gnu/store/gki8ja7hkzd29g97hnpr2snswnz4wdif-alsa-plugins-1.2.2-pulseaudio/lib/alsa-lib/libasound_module_pcm_pulse.so <lfam>Are you saying that your audio doesn't work, gnoo? <lfam>In what application does it not work? <lfam>Did you install alsa-plugins and alsa-plugins:pulseaudio? <gnoo>i installed alsa-plugins that pulled in alsa-plugins-pulseaudio <lfam>No, it doesn't pull it in <lfam>It might end up in /gnu/store, but that doesn't make it effective <lfam>You have to install both of them, and then Guix will export the environment variable ALSA_PLUGIN_DIR, and that is how this interface works on Guix <gnoo>ok, i'm installing it now <lfam>After you install it, you'll need to start a new login shell to test it <lfam>`bash --login`, for example <gnoo>i did that and it's still the same error <gnoo>ALSA_PLUGIN_DIR=/home/me/.guix-profile/lib/alsa-lib <gnoo>alsa_plugin_dir is set too <lfam>That's weird that "alsa_plugin_dir" is set <gnoo>i mean i all uppercase :P <gnoo>this happened after a guix gc today. it was working fine yesterday <lfam>I have mpv, alsa-plugins, alsa-plugins:pulseaudio installed in my profile, and the audio works <lfam>If it broke after `guix gc` and no other action, that means that something is caching store paths erroneously <lfam>But overall, it should work <lfam>Your next step is to debug it. You can launch mpv within `strace -f` and check while file is missing. The error message is probably not naming the missing file for you <gnoo>i did guix pull and also guix package -u and then guix system reconfigure while attempting to solve a gtk issue so any of them could've affected it too <lfam>Well, in any case, my next step would be debugging with strace <lfam>To clarify, have you installed these 3 packages in the same profile? Like, all with `guix install`? <gnoo>yes, all with guix install <gnoo>strace gives quite a lot of errors, should i paste it here? <lfam>You should search it for the error message and then read the context to understand what it cannot find <lfam>Oh, you should also make it show the full output <lfam>`strace -f -e abbrev=none` <podiki[m]>apteryx: I will have a small patch for imgui (some files were not being built), should I send that to a new issue #? it is features mangohud uses, but would say it is more generally how imgui should be built <pranavats>I'm trying to install guix with LVM on Luks2, and I'm unable to get grub to boot from the encrypted volume. Let me share the relevant part of my config. <lfam>gnoo: And, does that file "/gnu/store/1adbrln88chyshjsswcqfbr9cg9li25k-alsa-plugins-1.2.2-pulseaudio/lib/alsa-lib/libasound_module_pcm_pulse.so" exist? <gnoo>lfam: no, even this doesn't exists: /gnu/store/1adbrln88chyshjsswcqfbr9cg9li25k-alsa-plugins-1.2.2-pulseaudio/ <lfam>So, where does this filename come from? <gnoo>somehow mpv tries to load shared libraries from it, i think <lfam>But, how does mpv generate that filename? <lfam>It's a media player, not a random filename generator <gnoo>um, i don't know but i have this in my mpv.conf: ao=alsa <lfam>Well, you could remove that and just use Pulseaudio directory, rather than using the ALSA plugin for Pulseaudio <lfam>But, it doesn't explain this situation <lfam>Something, somewhere, has recorded this filename that used to exist <lfam>Maybe a config file or a cache file in $HOME <lfam>I meant to write, "... just use Pulseaudio directly ... " <gnoo>pulse audio was giving me problems with mpv so that's why i use alsa <lfam>Now you have ALSA problems :) <lfam>In general, we aim to make everything work by default with Pulseaudio in Guix <lfam>Anyways, try to remember if you made any special workarounds in the past where you pasted this filename or similar, or delete ~/.cache <gnoo>i couldn't find anything suspicious under HOME with find . -name '*alsa*' 2>/dev/null <pranavats>jpoiret: Could you take a look at my config in the screenshot above? I can explain the disk layout if it's unclear. Grub just fails to mount the crypt. Thank you. <lfam>gnuu: Well, that would only find files named with '*alsa*', but it's more likely that a file contains the string <jpoiret>if that's the case, you need /boot/ unencrypted, as i said <jpoiret>here it's on the LVM which is on LUKS <jpoiret>as a workaround I could send the patches I have for grub <jpoiret>but they're not reviewed yet so more risk involved, although it should be relatively safe <lfam>I tested on Guix System, and mpv works "by default" with both ALSA and Pulse outputs, without installing the plugins. The plugins should only be required for this on other distros <gnoo>yeah, it was working yesterday, also i just tested ffplay and it works <pranavats>jpoiret: I'd love to take a look, although I'd probably change boot to unencrypted for now. <lfam>I would remove (or move) ~/.cache <lfam>If there are caches elsewhere... that's a pain <gnoo>i moved .cache to .cache-old and it's still not playing <pranavats>jpoiret: I am a little confused though. I had /boot inside the encrypted root, and /boot/efi unencrypted, with luks2 before this. And grub booted it just fine. <lilyp>apteryx: you mean the patch to bind all font directories? <gnoo>i'll try again later. thanks for the help jpoiret, lfam ! <yarl>I head on last week end guix conferences that emacs-guix is broken? <jpoiret>pranavats: /boot/ needs to be unencrypted itself <jpoiret>basically, grub-install will put its files (including the modules, especially the cryptomount module) inside /boot/grub/, and so will need to reach them <jpoiret>it can be bypassed by baking the cryptomount module inside the installed grub binary but there's a bug with LUKS2 that prevents it from being included <teddd>Is there a way to do something like "guix time-machine" but in a manifest file ? Like is it possible to declare a channel for each specific package ? <attila_lendvai>is there a way to turn up shepherd logging? i'd fancy a backtrace for this: herd: exception caught while executing 'start' on service 'bee-mainnet-1': In procedure string-prefix?: Wrong type argument in position 2 (expecting string): 1528 <jgeerds>Could someone tell me where the activation point for "guix home" is in case of a foreign distro? Should it be "~/.profile" ? This file is not sourced on my machine (running Gnome under Wayland). I guess that's more a Wayland issue than a foreign distro <vivien>attila_lendvai, where is that service defined? Do you get 1528 every time, or is it a PID? <attila_lendvai>vivien, it's #o2770, i.e. some permissions end up at the wrong place. it's most probably a bug in my service code, although if i reboot the machine, then it seems to work. my issue is the utter undebuggability of shepherd, not this specific bug. <attila_lendvai>i'd venture into adding proper logging to shepherd, but then i don't know how to run/test shepherd itself *attila_lendvai tries a reboot and hopes his server comes back online <vivien>shepherd is one of the most debug-resistant piece of code I know, cuirass is not far from that <podiki[m]>if you search for "pinning" in the manual you'll find this as well <attila_lendvai>well, my server didn't reappear... :/ i've been seeing some kernel crashes recently at boot. <blake2b>hi folks, I just realized that I forgot to copy and paste the group discussion sketch pad from my session during Guix Days. did roptat or perhaps zimoun happen to collect them? ***iyzsong- is now known as iyzsong
<blake2b>sneek: later ask roptat if he happened to save the discussion notes from day 1 of guix days <unmatched-paren>trying to build guix from source, but `make` fails with `error: tcc: unbound variable`... the only file i changed was gnu/packages/dlang.scm, and there's no mention of tcc anywhere <djeis>When I try to write code against guix geiser seems to automatically find my current guix but it complains that it can't find the (gcrypt hash) module- am I missing something obvious? <podiki[m]>sneek: later tell apteryx submitted a patch to fix the imgui build (missing features) <unmatched-paren>(i'm trying to change the ldc build recipe to build using gdc, which will allow us to remove all the bootstrap packages for it.) <unmatched-paren>i'll just build it with `guix build`... i only change this file, so it should work <blake2b>hey guix, folks might have heard me mention a few times during guix days that it would be nice to have some way of synchronizing calendars for accomplishing tasks within guix and generally knowing whats going on. and then it hit me, why don't we just integrate caldav support into sneek? it could be a fun weekend code jam where we can setup emacs pair programming, kind of like with jgart's meetings. is that something others would be <lilyp>blake2b: how do you imagine this would work? "sneek remind me in two weeks to review this patch" and then sneek messaging you in IRC? <blake2b>lilyp: something like that, but more of a TODO : WIP : DONE kind of system <lilyp>I don't think a distributed, hardly moderated TODO list will work fine. <blake2b>so I could say "sneek add to my TODO x in Guile Documentation" but then I could also say "sneek show me what lilyp" is up to <blake2b>and so then others could add to x categories things todo, cross them off, keeping track of various things happening in guix <blake2b>and it could also be a go-to place to see what people are working on <blake2b>like if I'm packaging something, I could tell sneek WIP: packaging notcurses <unmatched-paren>is there some command to check whether there are any new commits in the guix repo without actually pulling? and maybe how many there are? <blake2b>and then if someone else is packaging notcurses, I can find out and our work doesn't conflict <blake2b>someone might also find that there is an old half-finished package hanging around, because you could leave the link to your repo with them <blake2b>unmatched-paren: why not git status? <unmatched-paren>as far as i can tell, there's no flag in git status to show whether there are any new commits... <lilyp>I don't think people like poking into the internals of their package cache <lilyp>also you'd have to git fetch rather than pull <lilyp>for the record, you could pull to /tmp <blake2b>unmatched-paren: I think you just need to explicitly setup the remote, and then it begins tracking <unmatched-paren>i guess git doesn't provide a way to check for new commits on the host? because i certainly can't repull every time the update check is refreshed <unmatched-paren>that would also mean i'd be pulling guix.git twice, once to check for updates, and once when i actually run `guix pull` <blake2b>yeah I think you just need to explicitly set your remote. then it will tell you how many you are behind <unmatched-paren>so i'd just need to run `git status` in $WHEREVER_THE_GUIX_REPO_IS_HIDDEN? <blake2b>or something like this, I forget the exact order <blake2b>ah, thats what it is, you run git checkout --track <remote> <unmatched-paren>ldc has such a huge #:phases, especially now that i've merged all the ldc-bootstraps into one <lilyp>unmatched-paren: TAB is your friend <unmatched-paren>(please don't suggest using emacs instead, i actually used it for a while) <blake2b>well, that little snippet will make it so that your error messages come out pretty printed across multiple lines, as opposed to a tightly mashed up across one long line <sneek>Welcome back apteryx, you have 1 message! <sneek>apteryx, podiki[m] says: submitted a patch to fix the imgui build (missing features) <blake2b>(guile should ship like this IMO, it's marketed as a beginner friendly scheme so shouldn't assume that the worst possible defaults are preffered) <blake2b>let me check, there might be another piece from my .guile required <blake2b>but a little more UI then I think is desired upstream <unmatched-paren>even with that pretty-printer, debugging is still pain compared to (gcc|clang|zig|ldc|gdc|rustc|...) <blake2b>oh sorry, you need (use-modules (ice-9 pretty)) <blake2b>hmm... let me look a little deeper... i'm hacking my repl all the time and actually have it setup with an experimental printer atm <blake2b>and copied that one, which was commented out (its a mess) <unmatched-paren>data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wCEAAoHCBYWFRgWFRUZGBgZGB4cHBwcHBkdHB8eJRwaGhwdHhocIy4lHB8sJRoeJzgmKy8xNTU1HCQ7RDs0Qi41NTUBDAwMEA8QHhISHjQrJSs0NDQ2NDQ0NzQ0Nj40NDQ3NDQxNDQ0NDQ0ND09PjQ0NDY0NDE0NDQ0MTU0NDY0NDQ0NP/AABEIAIwBZwMBIgACEQEDEQH/xAAaAAEAAwEBAQAAAAAAAAAAAAAAAgMEBQEG/8QAPhAAAgEDAwIEAwUHAwMEAwAAAQIRABIhAwQxIkEFMlFhE4HwI0JxkaEGFDNSYrGyFcHRkuHxcoKi0hZDU//EABgBAQEBAQEAAAAAAAAAAAAA <unmatched-paren>AAABAgME/8QAJhEBAAICAAcAAAcAAAAAAAAAAAERAhIDEyExQVFhIjJCcYGRof/aAAwDAQACEQMRAD8A+W2e0VxpySC+oyewj4cfrqfpWnb+CO6I4jr4GZ8wHbnmfkaw7bWZQLWIgkiDweJHofertloK7EN/KSACqliOFDMCB+Xat5TrFyxM0uHhWJJOULrAJmCsjkHF3PseRmpJ4MSYm2VQi4MJuR9T0wANNv0qzR8KRgpOsouAPCnkKf5uMlZwZVsV5r+GBA/VcVS6MDN4BB6j2kj8DgRnnzsLq/8AE2hJ/ADIsaQQskhhEtaJifriarTwaVBDjLAfe4KaeorRyBGpBPraO9W6myDs/WSJQKzMG6WIBMzmAePaqdbw4BGcOGC24gfeGmc9Rg/ae/l <unmatched-paren>OascbGZqzaHv+hN2ZSSTHmAOHPmOAYRiR2EHvVml4DLorOoBe05gg3FRF0BiSDgVVt9ijqhvtJ8wIB/8A6kRmZ+zAj1cZzFT0vDVcgK8CGDNgiQ4QGCRaLWDZNdFS23ggZVYv5kZumGAIKADB/rzMAEHI5rw+DLDMGYAIHFwYHjUJuBAKj7OPTqGTwa9LYo4QK8MUucmI/iHTxkcAXZyfnjNuNNQy24VkRhJnJVbsj0a4fKqNu48GRWKByTKKsggSzskt6Donjhh8z+DKFLS5IKC20hiWXSNueGnUwD2Q/KrdbFELD4l0FQIUZLX5y2FFgyJ84qQ8OQkxqCBqWSVUfeRbvP8A1lh6hGyKCP8Api3CCzIzsoKqzGAWE9IOemYEm3MVDb+HBtR0ui0kA5 <unmatched-paren>gm9UExOOrtNV7Xbo7hL7VP3mUTxOVuj9a2/wCkpKr8ZTJYSFxgkDMx2z6T6ZoKG8JtUE5LaZdQsngK0H1w3bgg+mfdfwoJfe3GneIByb1083dpaZ71LQ8MVgv2ii5L8gYOBbBMxnzcYqzceGiGdtWTZf5ZLZcSCGPT0Dq/rGKgz7rwooHuBuUrxMWltRZIIkZQZ/qFR23hZdA4IAZwgknklRmOPOD8j7T7sNqrdTOECugMgcMwWRODGSfQCpbrbj4kAXLKAwUBllBKyFAmbhNvbNUV6PhoYAq83F4EPJCKHYgdzmAOSfSobrZBIBYEktgXcK76cz3yhrQmyX4zIxNgd1BlZNoJUTByenMd8VDS0lGqyKQyi+DCm4KGKxIIlrQJ96C4eAtarXr1Jf8Ae <unmatched-paren>kDpx7+ft6VU3hDAE8wgfvkGfXiLTzn2qSbRHC2yWOm7thYuBcKBBwOn9R649OyQh2D2gIjqPMWJSWyOAHUrPaRQWt+zzgwWUcc3d2CdREhcn5gH0qj/AEsBihYyHRJAJw6u3l5kW/XNRTQIVwC3VYqqIFztDAHmVAnvyU4nFult0mC7WFwoIIglV63jiMiO/WM4NBnbw77VtPMgtzkwAW4UmSQMAdyBV3+jm1XJtVr8kNICqzcc5CHHrVy+FoSJ1hBaJhT/ADn+fzdIJHa8ZNQ1PDUWD8QMssWtEQqk8GSLjAEerrzzUEU8EYhSGHUtww/ppn04+0EtwIaeM59rsA6OwMWQe8Ra7GSOP4cCcSa06O0+IEBe0fDLi6IBvZIAnjpHV7U1PDQAx+IDCXiA <unmatched-paren>MiW73YkAEesgek0R3HhbIHLBjZExcBF7pyRjyyPYipbjwuxdVpMablRgyYdFBJ4EhwR6/hXp8OUswVjaGQBiFiHMFsHtP/io6Oy0563NhHSRAP8AD+I0jq4lVjuW9ooOfH1JpH1Jrtavh2lCFHdg0/eUSbGYL5OliQBmTng1Tq+HIoU3g2l/iWsDCgmy0wJuC4J7suBMUHLj6k0j6k1v0Nir2gOASgYyBAlgsA3ZIBJOBxR9koDdZY/CDqAByWAKkEzgEn3GeOQwR9SaR9Sa6a7BDKl7XVgpLRbPSH9CApJzmbe00Xw5S1gckh1UtEdLIT5CexETMZoOZH1JpH1JroPs0i0OS5Zx92IVA4XnzFmt5iQYmM1b3bqgFpu6nUmRBKuQCB2lYPfmgyR9SaR <unmatched-paren>9Sa3vskChjqcpeQFkzOmLRLAE9Zn0sNeDZqVYh8qisRAiSh1IBumAQEmPMwxQYY+pNeFfqTWp9uo1AgeReFLkADzWkgXGR35FbH8LQcawPWFwsmDbkgMY8xgd7TQciwfU0sH1NdMeGiY+IPOyHA4UMZHV1TbwOJHqJvHgy99YRcyyFBBgkdMNLHExjE80HGKD6mvK0a+naEIPmUk/9brj2IUH50oK9BFtEnuZ49/+351NFUxJj8vWP7ZqrQjEkgd4Enk9iR/er9MJ94twZgAd8Rkz84/Gs6TPl1ji4xX4YRCL+PTPzqbhTJnMYMzmD7/hTaqhLXmBYbTk9WIwB+P1gzYaVpjzBEiS0FikvwuCGwAYETmpOH1rHjYxH5YQZEzx2jP+9EAJtuIQus5xnB <unmatched-paren>OTHzNa0Tb5VmIIa0MLiCAo64gzc12PSKiyaEmHlb0jDhithvAlcAOQB3x3wakYfTLi45fpiP2VbXQRtWx3tSX6pUTAYoLj0rcQq3HAungV19p4VtCumX3NhYkOodDAvAXMdhkyIMSDFcezTv8AMbJOOq6LZGbfUx8jijrplUIMMb716sclOq0+wiPxInG3B0tDw3asqltzabJYEph7NJjGMgF3FnmJ0zBrDvl01ZPhEhW00ZwXVjcVF4NoFsNIgjtPBFQ1zplUiAwQhgLvMFWCSU8xN0jI/qE4jv2QlSkDpFwEwDJ4LKpOIPHfk0Ha33hezDahTcgAN0KGVgAXIAu5cFYOMp96ayrtNqWj4rgHWZASyeRQpvbp4clgDwMEzBnj0oOv4nsdBNMtp7m83 <unmatched-paren>WhMSOp+qRgrCjI7kHgisvhmjpajqmq40lgy49jd1TIm24CAM21ipQdg+H7exWXWJY6N5Utpr1/Z9Mny23vhgC3w+nzCPdfa7d1Z/ispXQRkDaiOS/w2ZliARDqqWc9dw6RXGpQa/EU00d00iXQGA7EEmLgStsC0yOQTjmtXh2w0H0r9TWsf4gWwMgNl2mGMORBhmIabegzXKpQdHbbPRO5Om+qF0gzC9WBECbTcVg9sxmt/+nbRWX7a8MdRYDokFV1LCzFSFDFUEmB1zxXz9KD6HbeGbQopfcAM+nJ606HnSJgd8O4sYSbGjkGsx2e3ZXe9UI0NN0RXUy50ydRTexYQ622zdDgiQM8elB1/Ctntn0mOrqjScaigNMmw2g/Z8sMk4yI9KtbwzbXwNfp+ <unmatched-paren>IFJL6QtS1GJkSHks6hlwtktE44dKD6DU8J2oZQNzcpe3D6YIWNUyScAC3TF3HW0AnFYPEdloppo2nrXuWYOBbAALAQMOOBkrDXSI4rnUoOym20GVC7STtWIA1kkaod7VaZCAoVhSF9MsDWHY6KMmsWKhl0wUudVlr0kBSQWNl/HpESVrJSg373Z6S66omoDpsUliytaCQGLFAVBHJAuj1NbtfY7YGxdQEDWSXvS/4boCwEsEYo8rcvHJxXCpQdPf7HQRCyawdxqFbQQwKzqCeATAVDdFpvgeU1t23h20dNEtrhGZOsXL5rjJ6vIQIMHDRAzXz9KDpnbbYDLu0aN5goLnL6ahFBU2wCzGZOPbOt/CtoFJG7EqgaIBvMamFjyk2qbTJFwByRXBpQfQ7nw <unmatched-paren>3ZomsU172VOgFkEtIhhYeuRJjFvBHBrH4bstBtO99axxqBbVZAbJ0wxhyIMOxDTb0GYrlUoOhtdtpfvSo7q2kNWGa8BSgbLFyFkR6QTwIJFdLY+F7SwF9yUe0XhXSLsSFYAiAccma+dpQdxvD9sv/AO28tpuyw6JDhNJlDEgwSzaoAMTYPXNur4ZtFRyNwrOEV1618wXWLKAIuViumIgOLu2a+epQdzdbTb267pqhYsOmiupBBVSZva45uW3zLEkQRXBqVKCNSZyQASSBwJwJ5gdqUqiJpQ0oI6fH161exFqxE9U+vaJr3T1l+EEtzfddIz5h6SOR37UdhYg9C3+1UV0pUagUroa29Rg5sl3tIZlDQQBI82MgmYN0wRVOruFOsXAhS90WqIEzFo6fb3 <unmatched-paren>+dBnpXV09/oCJ0roZiSVWSCxIByZgGOewqv980gZVIJvBlEYAEagWA2CRcp7eWKDmUrq6W90goWwnotbpXqzpmCZ9VfriRcOYqr96Qh7ludkRQzCbSqWEg3DmFa7tEQe4YajWrQ1FTDKry6E8HoF16gnKkyuR6VpXxBAWFgsZ0YqEVQQqkREk+aGtug54mg51K3Ju9MMCdNbb3Y9A7oAmCeFaWtugz+Uju9LH2YEXQQqmJJM2seuMABiY9fUOfSr91rIyoEQKVWGMQSYUEkybsgngRdGcVHcaiMVt07APMLyZ9ckYoKKlXQ3G70mYtYTJUm7GbusDJhbYAE4zVTblJlUAhwfKMiFxkm3g8c3doq1HtL+MlK1/vCfySbiZgCfNGAfdccdPvVDkELA6uo <unmatched-paren>kBY7445x7CKTCxKulRpUEqV4FPp3j5+lCKD2leRXlBKlRqVApUaUEqV4BXlBKlKUClKUClKUClKUClKUClKUETShpQE0zaGg2kkAwYmTiauduhBnBb8O3FQTW6AkcEme/JwPQZz+AqbnoTHds+vFUV0pSoqNSq86jZ6fTt9TXlzeh8w7nmPr9K57T6enkYxPef6Z6TV7OZBZcBsiSJ4kT8ua3aPihVdNQlwQCZLZIe8RHlExMcxWom4ccsKyqLn+HMCkyQMDn2zGfmamNByCQjEAXEwYAzknsMHPtW3T8SdQoC8IF75UFTBj7vTHzOTiKv3iLpTq+GqXXeUBfhyBHcAA/POTVuGdMvUsjqQYIg+hpV+rrXSLSCQigT2RQgkdyYGe2aotPoaXBrPopS0 <blake2b>oh shit its a base64 of a whole jpeg <unmatched-paren>+h/KvIpZOMx3h7Slp9K8tPpSzWfSStgiAZjJmR+EGM+9SOoP5F5B+/8A9Pm4/X3qBU+hpaeY9qWaT6TGoP5F5n7/AP0+bj9fevdvqhWuKyIIgGORHJB9artPofypViUnGfLcniKgKPhKYEds8c9PtUH3oIICQGS0wRzddPl47R+tZKVraWdYbtbxBWVlGmFnjIwfXy8xHccVVrbpWDiwAu5e6QSJIJHH4/nWalScpkjGIatLeAKqlAbZzI738Spg9U5kdIxXn73nCKAA0CF5YsQcjtcBH9NZqU2k1hsTeqAJ01MAegyIzheMEwZyx/CqNDWCqwKhrhEmMYYenuDiMqM1VSm0rrDWd4sk2DLKY6cAGbfL5f1xya8O7EiEAEqY6TICosTb3Kz86y0ptKa <unmatched-paren>wuTcQ5cLE3QJ4uUjuMxPpVz75cRpqpF3ofNMcr2kfl2rHSm0msLdxrhggCBbRBIjOBnj2n5mqqUqTNrEUUpSgUpSgUpSgUpSgUpSgiaUNKCSaLBA8dJJAPvJ/4NWOTYmMS0fpNVprNYEnpmYgep789zj3qx5sTiJaPXtM1egg6EQf5hI/Mj+4NeVPVZiFBEALC8wRJJOecntVg2TnyiekMcrwcjvnjtSvRftmpWl9k45WO/KxExMzUl8PckiBhrSZETTWfRszVYuuRHGKn+5v0gCWJYQDkWgE54iGBkGo6W1ZmZQIZZkExkELE8TJrM430mG8OLlhN4zSKapHpxH+9H1SeY4/3mpfur+kYnJUQOnmTg9a4OeoV6u0c8AcA+ZeCCw7+gJj0BppF3TXPz <unmatched-paren>qr6K21CTPcf+a9+MfbkfpH/Ao2gwIUqQW4HcyYH6irDsdTPRwY5X0B9eIYZ4zU0j0nPzi+vdSNQ49p/XmvX1Ceas3G1ZMkCJiQRBP96kmxdgpVbrhIgj1jM8f96unXt1TnZVV9JU/EPHtH9v8AgUOoc8ZEfoR/Y1Yuyc8LOLolZj1icVnqaRHhednPlYdQmfeiahHH1x/xUaUqO1HNzu7m0/imZ/H9cVWTOa9pSMYjsk8TLLpMlKUrTBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKCJpQ0oI6fH161azkgDsJj5/+K80NIlQZGSf9/8AipppTEHn8fWKztEeXaOBnNVHfshV370/854jtwOBXmnti0weEZzhzgCT5QY/EwB3IrX4X4Q+u <unmatched-paren>uq6EAaS3NPfpd4Ed4RvaYHerGXmHLLGYmpZG3TkEFyQRBHtzT97f+c5M/PGf0H5V3d9+yTo2pDoVRoEhw0FyguBWFPpMXfdms6eAAzbqXldwuiwRHPPLSRIyCBIzFXb6mrk/vL/AMx5J+ZEH8xivNPWZTcrEE9x+ddtv2XecMF+0dLWVy4C/HIMKvVI0GgKJMrjNZ/DfA21d022uAscq7AMcLqLpsVABJy05wACTgGllOY2sxEFiREfKQY/+I/IUGs2eo5AB9wBAH5Yrt7f9ltV1DB0AZLxdcJWzSfEDI+1CkjAKN7VzfDtiNRdVr4Onphwtpa4FlUyR5ALgSxwOTgE0taZn1mZrixLes55nmpDdP2YjM/2/wDqPyrbvPBn09wm3ZlLOyqDDAC5ymQw <unmatched-paren>BAkE8ZWCMEVp/wDxp71Q6iBmdUUEOJJTT1MyvTC6gw0GRFLSnHfWZsFiZMn8fX9T+deruHAADGBxXb0v2Zf4iIzqQ+uNE2Bi13UzCLZEIFYkiAHHoa82f7K6zrpkFQX+6Q9wNwUgi3JWSWibYgwaWtOINZh948R8uwqqt3iHhzaSabsQRqoWWJ7RIz3Ej/aRk7d9+zz6Ksz6iALpq+L2m4lVUQuZI54g0spxqV23/Zt/tLdRG+E4R8OOosFIkrA5ET5sgTFcrfbcabugcPYxUsAwEgwYuAOCDURTSlKoUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgv8OAOooIkZ5/9Jr2vfDf4q/P/E15QY9Pj69alUtBFtEnuZ49/r51NFUxmPy <unmatched-paren>9Y/tmsbQ7RwcprrHX6qihFWFR69p+fpVmgilHJi4RAJjph7mGRcwISFzMnB7aibc8sZxZgo9BXpUeldLcbTSUOV1A1uQpZTOYAlYukCccTByK83GhpBdUqwJDkIA4PTelsCZaVLZ7RnNVlh0NQowdDaw4I5Hao6jFiSxuJJJJySTkkk8mtuht9MqpLwxmRcqjjUgSR0mUQScdYqG700ULYbsuCbhmGIU2RKgrB78+1BjtHoK9IroaW10zEvHQDNyeY23C3kWyenlrcVfr7DRCuyak248yc2ajDtmSgWBnJPag5Wk5QhlNpUhgRgggyCPeajFdB9BJK3KvVpdV4YhCpGpwYYhowBOOwrNuVVXITqURyVM4BIJQwRMiQfyoM9o9BSwegrpaGhpMqXPa2b ***ChanServ sets mode: +b *!*@host86-134-140-17.range86-134.btcentralplus.com
***unmatched-paren was kicked by ChanServ (User is banned from this channel)
***ChanServ sets mode: +o litharge
***litharge sets mode: -o litharge
***ChanServ sets mode: -b *!*@host86-134-140-17.range86-134.btcentralplus.com
<apteryx>sneek: unmatched-paren please don't share these amazing rust errors with the channel again <apteryx>sneek: later tell unmatched-paren please don't share these amazing rust errors with the channel again ;-) <unmatched-pare>...really, really sorry, i misclicked and hit 'copy image' instead of 'copy image address' :( <sneek>unmatched-pare, you have 1 message! <sneek>unmatched-pare, apteryx says: please don't share these amazing rust errors with the channel again ;-) <apteryx>unmatched-pare: for what it's worth, you may be interested in configuring (or looking at client which has that feature out of the box, such as weechat) to warn you before you attempt pasting the universe :-) <apteryx>I once received such advice myself, and it has paid off more than once. <blake2b>unmatched-pare, it happens, but this is why you should use emacs ;). for the repl, you also need to include (system repl common) in your .guile use-modules <nckx>My bouncer sent me mail. <nckx> ChanServ removes ban on *!*@host86-134-140-17.range86-134.btcentralplus.com <blake2b>re: guile UX, I think the philosophy is that of emacs; give the users the minimum they need to design their own setup. but the problem is that, unlike emacs, there is hardly any information on building your own guile interface. in fact, I think its something mostly missing from the guile docs. <blake2b>lilyp: see, thats something I want to "tell sneek TODO: add repl interface article to guile docs" <blake2b>things that come up here, during conversation, etc <blake2b>i did the first few chapters of the rust book, its super pleasant <unmatched-paren>it can be pretty confusing (it certainly needs the good error messages!) and cargo should be buried in the desert, but the language is really good <unmatched-paren>guix still isn't pretty-printing the error messages, even though i added (system repl common) <unmatched-paren>i wonder if racket and chez have better error messages, i'll try testing them <blake2b>if you have (activate-colorized!) (activate-readline!) the option-set! should come after, i think <blake2b>hm, don't know what the issue is then <blake2b>w/ Racket, the error messages are a bit cleaner, but you don't get the full view of whats happening <blake2b>I've come to appreciate Guile's error messages. it's like if Brecht designed error messages (: <blake2b>you just have to learn how to read them <blake2b>but once you do, they are pretty clear <unmatched-paren>i think the way guix executes code in the store makes it a bit more confusing, since you don't really get an exact backtrace <blake2b>if you were an emacs user, you could just run your cursors over ice-9/read.scm, click it, and it will pop up a window showing where your error occurred <blake2b>i imagine you can setup vim to do the same <blake2b>if you put some elbow grease into a geiser-guile repl, I'm convinced you'd find rust to be less effective debugging experience <unmatched-paren>apteryx: actually, there _was_ a warning (i use irssi) but i wasn't aware that i'd clicked the wrong menu option, so i just selected yes without thinking <blake2b>but debugging in scheme is all about programming your own debuggers. I'm always designing little tools in a module I have called (derive trace) that I use for debugging. its a rouger start but it pays off <blake2b>it is! what other programming language can spend an hour hacking and have a nice little debugger handy to aid in your day-to-day? <blake2b>so much good scheme content scattered across a bazillion website, journals, mailing list posts, etc... I have a massive set of bookmarks and have only read a quarter of them <the_tubular>Yeah I wish we had a nice wiki with lots of templates <blake2b>i'm very glad I decided to take the dive and focus on guile a few months ago <blake2b>I remember it came up a while back too, but the conversation quickly turned to that we should build it in guile, and then diffused <the_tubular>Is there somewhere I can check the up to date list of to do ? <blake2b>while I love building everything in guile, for this perhaps we should just settle on an org-mode to wiki exporter, it seems org-mode is a quite common form of organizing among contributors <the_tubular>Both would work for me. I'm still very new to guile and slowly learning <blake2b>tbh, it's been the roughest experience learning a programming language I've had. I was using racket before and thought the transition would be simple, but the docs are just an organization nightmare to navigate. but now that I think I've made it "over the hump" (I'm now using guile for every little thing I can with little down time) I'm deeply appreciative of the compiler infrastructure and how much it offers <blake2b>true, and not editor exclusive. but org mode we could do it from a single doc and it would be very easy to organize <blake2b>things like an interactive table of contents, etc, so that you can find where you need to make an edit and quickly be in and out is a big difference imo. in markdown i think you would have to make a directory for each category... navigating something with hundreds of entries like that is a nightmare <blake2b>if there is a markdown solution that allows you to fold entries in the editor, hot link etc, lmk tho <alanz>(my first time attempting this, likely some very newbie mistake) <nckx>alanz: You're nuking all of imagemagick's arguments (configure flags, phases, …). You probably want to use substitute-keyword-arguments to avoid that. <alanz>do you have any pointers as to how I can do that? <nckx>Besides ‘grep gnu/packages/*.scm’ for examples, no, not at the mo, sorry. <nckx>However, that zone is rife with pertinent examples. <alanz>ok, thanks. That was my next step, look for similar examples 
