IRC channel logs


back to list of logs

<AwesomeAdam54321>22/whois adamcstephens
<the_tubular>I'm still having the guix upgrade issue, am I the only one ?
<the_tubular>Also, how is debugging handled in guix packages ?
<AwesomeAdam54321>the_tubular: I have the guix upgrade problem as well, guix package -u upgrades packages even though they're already upgraded
<the_tubular>Yeap, same thing as I have.
<the_tubular>Weird, mind if I asked what is the package ?
<AwesomeAdam54321>the_tubular: emacs, git, git:send-email, icecat, icedove, irssi, lagrange, magic-wormhole, minetest and wine
<the_tubular>Umm, that's a lot
<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>Is it possible to have more than 1 locale ?
<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
<ajarara>Hi Guix! I'm trying to package git-secret. Here's the def: . The tests fail because git does not see git-secret on its $PATH. Is this because git has its own isolated path? I thought that only applied when building, not at runtime.
***dgcampea-2 is now known as dgcampea
<the_tubular>Ooohh, are you gonna push this upstreasm ajarara ?
<ajarara>yes, if I get tests working!
<the_tubular>I can't help you with your problem though :/
<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.
<the_tubular>Seems to be a PATH env problem
<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
<and-lan>Hello guix!
<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.
<sneek>Welcome back abrenon
<abrenon>good bot
<abrenon>sneek: botsnack
<sughosha>Hi guys, is there a way to exit from `guix repl`?
<balbi>sughosha: ,q
<roptat>hi guix!
<roptat>sughosha, or Ctrl+D
<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..
<abrenon>hi roptat
*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
<unmatched-paren>zig uses git submodules to fetch dependencies
<the_tubular>Can a service create a text file somewhere ?
<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
<the_tubular>"activation script" ?
<efraim>rictjo: can you share the build error on
<rictjo>the error I am seeing is `GLIBC_2.33' not found (required by /gnu/store/...-julia-1.6.3/bin/../lib/julia/
<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
<the_tubular>I wanted to try and fake those conditions
<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: are you on x86_64?
<gnoo>jpoiret: yes
<PotentialUser-69>Hello! May I ask if GUIX can be installed on nokia n9?
<jpoiret>gnoo: does `grep svg ~/.guix-profile/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache` give you anything?
<gnoo>jpoiret: this is the result:
<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
<jpoiret>I have only one personally
<gnoo>yes, there are two of them
<rictjo>efraim: thank you for your recommendation. This resolved the issue
<efraim>glad I could help
<jpoiret>gnoo: this might be the issue but I wonder how that could happen
<PotentialUser-69>I did not understand anything, but thanks for the responsiveness!
<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>we can test out something
<gnoo>ok, what should i do?
<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
<jpoiret>let me try the same thing=
<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 ?
<jpoiret>is LANG=something.UTF-8 set?
<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>ohhhh, it does change
<jpoiret>does setting it help?
<abrenon>makes sense, I don't want a "pure" shell to depend on some accidental variable set outside of it
<abrenon>works like a charm !
<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" ?
<jpoiret>you can't :)
<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 --`
<abrenon>that's hideous ! ^^
<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
<jpoiret>à la guix home/system
<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 ?
<abrenon>it's not only about files
<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
<abrenon>I wonder my LANG is even set at all
<abrenon>I shouldn't have worried about that
<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>works with en_GB.UTF-8 too though
<jpoiret>ah. i don't know why then
<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
<abrenon>but it does
<abrenon>I can't help but wonder
<pranavats>Does Luks2 work well with Grub2 under Guix?
<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>that may be why
<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
<jpoiret>you have the same thing on win$
<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
<jpoiret>(i've never used those though)
<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
<abrenon>I'll get over it, don't worry : )
<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>it can be your EFI 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>seems pretty terrible
<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).
<ceephax>would someone mind pointing me in the direction for testing patches, i'd like to test this one on my system
<jpoiret>ceephax: you'd need to follow
<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.
<ceephax>jpoiret: thanks
<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
<pranavats>No I was using it with guix.
<pranavats>Anyway, I converted the keyslot to pbkdf2.
<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 '' in a '[STORE-php-location]/lib/php/extensions/no-debug-[...]/' directory, but have no clue how to
<tschilptschilp23>'enable' it...
<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>Links from the Guix doc to the Cuirass doc are broken apparently. E.g. from
<phf-1>When clicking on ̀Specifications' in  `(see Specifications in Cuirass).'
<AwesomeAdam54321>phf-1: It looks like the Cuirass manual is now at
<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>yes... i'm little dumb
<phf-1>just a little
<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)' ?
<phf-1>sneek botsnack
<phf-1>Yes! Got it \o/
<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>that's weird
<jpoiret>aspell uses hunspell dictionnaries right?
<gnoo>i'll install it again just in case
<gnoo>yes, i think
<jpoiret>i haven't used any of those
<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
<jpoiret>it's actually always outdated
<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>where's your shepherd user from?
<jpoiret>guix home?
<gnoo>no, i manually start it
<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
<jpoiret>in .cache/guile/ccache/ maybe
<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
<jpoiret>since it'll have to compile again
<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>and again once after this
<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 :
<phf-1>Strange, `guix install nss-certs' fails but other packages succeed like `guix install emacs' :
<gnoo>and this is my ~/.bash_profile :
<jpoiret>where are you sourcing .config/guix/current/etc/profile then?
<jpoiret>you need both profiles
<gnoo>i'm only sourcing ~/.guix_profile, isn't that the default one that is used?
<jpoiret>.config/guix/current/ is the guix pull profile
<jpoiret>so you also need to activate that one
<jpoiret>it contains the guix you guix pull
<jpoiret>but your PATH has it so I was wondering how it ended up there
<gnoo>ok, i'll do that too
<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>interactive login
<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>but yeah no need to do that in bash
<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?
<jpoiret>also i use channels
<jpoiret>yes, `guix describe`
<gnoo>ok, yeah, it's 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>that audio doesn't work is weird
<jpoiret>do you use pulseaudio?
<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/ (/gnu/store/1adbrln88chyshjsswcqfbr9cg9li25k-alsa-plugins-1.2.2-pulseaudio/lib/alsa-lib/ cannot open shared object file: No such file or directory)
<jpoiret>does that file really not exist?
<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>did you run `guix gc`?
<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>is ALSA_PLUGIN_DIR set?
<gnoo>no, it's not set
<jpoiret>nothing ALSA related?
<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
<gnoo>yeah, i'll just reboot
<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
<ceephax>mbakke: thanks
<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
<nckx>Yodelahiti, Guix.
<abrenon>hey nckx
<jpoiret>i see you've effectively banned gm from your vocab :p hi nckx
<abrenon>+1 for the tyrolian feel
<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
<abrenon>sieht lecker aus, : Þ
<nckx>It is.
<nckx>Meanwhilst, back at the topic (sorry): is anyone using bcachefs with Guix System? Anyone?
<abrenon>didn't even know about it
<nckx>It's still experimental.
<jpoiret>i'm already living on the edge using btrfs
<jpoiret>i don't want to take more risks
<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!
<abrenon>bis bald
<jpoiret>good luck
<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>dear god no
<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
<nckx>Thanks for the hint.
<sneek>phf-1: Greetings
<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/ (/gnu/store/1adbrln88chyshjsswcqfbr9cg9li25k-alsa-plugins-1.2.2-pulseaudio/lib/alsa-lib/ 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/
<lfam>Are you saying that your audio doesn't work, gnoo?
<gnoo>lfam: yes :^)
<lfam>In what application does it not work?
<gnoo>with mpv
<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 is set too
<lfam>That's weird that "alsa_plugin_dir" is set
<lfam>That's unexpected
<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
<gnoo>ok, installing 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?
<gnoo>i mean output
<gnoo>on a pastebin*
<lfam>You should search it for the error message and then read the context to understand what it cannot find
<lfam>But if that's not something you can do, then you can put it on <>
<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/" 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>pranavats: you're on LUKS2, right?
<jpoiret>if that's the case, you need /boot/ unencrypted, as i said
<jpoiret>here it's on the LVM which is on LUKS
<pranavats>Oh. Let me make the changes.
<pranavats>Thank you.
<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 suspect a bogus cache
<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
<jpoiret>time for strace then hehe
<gnoo>jpoiret: this is strace's output; the mentioned file doesn't exist:
<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.
<pranavats>I probably remember it incorrectly.
<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
<lilyp>if so, go ahead
<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
<apteryx>lilyp: yes
<apteryx>thank you
<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]>teddd: perhaps you want to look at inferiors/pinning, like in
<podiki[m]>teddd: and
<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?
<zimoun>blake2b, no I didn’t, sorry.
***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
<sneek>Will do.
<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
<unmatched-paren>it happens after it prints this:
<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?
<unmatched-paren>[ 11%] LOAD guix/tests.scm
<podiki[m]>sneek: later tell apteryx submitted a patch to fix the imgui build (missing features)
<sneek>Will do.
<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
<blake2b>interested in?
<blake2b>here is the source for those interested:
<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
<unmatched-paren>i'd really like to have an indicator of the above in my desktop bar
<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>s/host/remote host/
<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>no you need to do git remote add origin main http://savnanah.blahlblah
<blake2b>or something like this, I forget the exact order
<blake2b>ah, thats what it is, you run git checkout --track <remote>
<unmatched-paren>i love guile errors:
<unmatched-paren>i have absolutely no idea how to debug this
<unmatched-paren>it's some missing paren somewhere i guess
<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
<blake2b>unmatched-paren: pretty-printing your errors will make your experience a whole lot nicer:
<unmatched-paren>it doesn't help that the editor i'm using doesn't support scheme...
<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
<blake2b>regardless of your editor
<unmatched-paren>it did not work :(
<apteryx>lilyp: here's the submission for your webkitgtk patch:
<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
<unmatched-paren>guile generally needs massive ui improvements imo
<blake2b>for real.
<blake2b>I'm working on a fancy repl forit
<blake2b>but a little more UI then I think is desired upstream
<lilyp>apteryx thanks
<unmatched-paren>even with that pretty-printer, debugging is still pain compared to (gcc|clang|zig|ldc|gdc|rustc|...)
<unmatched-paren>blake2b: cool!
<unmatched-paren>i like over-the-top repls; for ocaml i use utop, which looks like this:
<blake2b>oh sorry, you need (use-modules (ice-9 pretty))
<unmatched-paren>ah, thanks!
<blake2b>(ice-9 pretty-print)
<blake2b>not pretty!
<unmatched-paren>it, uuh.. still doesn't work :(
<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>rust's error reports are amazing:
<blake2b>oh shit its a base64 of a whole jpeg
***ChanServ sets mode: +b *!*
***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 *!*
<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 ;-)
<sneek>Will do.
<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 ;-)
<unmatched-pare>apparently my previous apologies were blocked...
<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.
<unmatched-pare>right, thanks, sorry for the flood
<apteryx>no worries
<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
<unmatched-pare>or a client that uploads it to $PASTESITE
<nckx>My bouncer sent me mail.
<unmatched-pare>is someone able to unban unmatched-paren?
<nckx>Should already be?
<nckx> ChanServ removes ban on *!*
<unmatched-pare>ok i'll try to rejoin
<unmatched-paren>thanks blake2b
<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
<unmatched-paren>this was what i was trying to say before: "rust's error reports are amazing:*H0M1IA5wYWVb2Gf-hZXJ9A.png (yes, i know it's cliched to lavish praise on rust)"
<blake2b>yeah, they are amazing
<blake2b>i need to learn rust
<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'll just pick through it manually...
<unmatched-paren>i wonder if racket and chez have better error messages, i'll try testing them
<unmatched-paren>if they do, we might be able to learn something from it
<blake2b>if you have (activate-colorized!) (activate-readline!) the option-set! should come after, i think
<unmatched-paren>i have it after both of those
<blake2b>hm, don't know what the issue is then
<unmatched-paren>okay, both chez and racket also have terrible error messages
<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>guile's are surprisingly the best imo:
<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>this is a nice tutorial from the docs on debugging in guile
<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>for example, heres a nice clean little macro, although its not general purpose:
<blake2b>this tutorial was very helpful:
<the_tubular>That's a great link blake2b
<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 just brought that up on the list!
<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 ?
<the_tubular>That was made during guix days
<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
<blake2b>you'll have to ask roptat
<the_tubular>Both would work for me. I'm still very new to guile and slowly learning
<the_tubular>But markdown is very easy to pick up
<the_tubular>Err Org-mode *
<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>I am trying to modify the imagemagick policy.xml to allow more RAM. My attempt is at, which fails because of some libraries not being found by the linker. I would assume inheriting from a package should bring in all its deps too?
<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