IRC channel logs

2020-01-31.log

back to list of logs

<raingloom>seems like tests/graph.scm fails on a recent commit. can't really investigate right now and my email client is broken, so can't send a bug either.
***pkill-9[m] is now known as itsme[m]
***jonsger1 is now known as jonsger
<apteryx>pkill9: has it been added already? I have it packaged locally, been meaning to send it. Also have a service (for which I must still write the doc)
<apteryx>(regarding earlyoom)
<pkill9>apteryx: i've sent a patch but it's not been added
<pkill9>this is what i've sent: https://lists.gnu.org/archive/html/bug-guix/2020-01/msg00302.html
<pkill9>apteryx: could you send a link to the service? i want to add it as a service, but didn't get round to fixing the one i wrote
<pkill9>i did it wrong because I think it killed the shepherd, lol
<apteryx>pkill9: hehe. I'll write a quick doc for it, then append to your existing patch on guix-patches
***Drakonis__ is now known as drakonis
<apteryx>pkill9: hmm. Wondering in which service category (in the manual) a user space, OOM software should go. I was going to add a new "Linux Services", because it's explicitly tied to the Linux kernel. Any ideas?
<apteryx>pkill9: by the way, if you can't wait for me to finish the doc to try it, the service definition is pasted here: https://paste.debian.net/1128428/
<plasma41>Are any of the Guix Days talks being recorded?
<drakonis>nope
<drakonis>its unconference
<plasma41>:-(
<drakonis>its what i've been told
<plasma41>I want to see them. I'm stuck on the other side of the pond
<drakonis>same
<jackhill>I bet some of the Guix-related talks at actual FOSDOM wil be though: https://guix.gnu.org/blog/2020/meet-guix-at-fosdem-2020/
*jackhill waves to the the other people on this side of the pond
<drakonis>well they'll all be, fosdem records everything
<jackhill>ah, cool. I know I've watch past videos, but didn't know it was universal. That's great.
<jackhill>I still hope to go one year though.
<bandali>leoprikler, are you around?
<apteryx>pandoc pulls a ridiculously huge amount of ghc dependencies
<apteryx>pkill9: I finished the documentation, going to send in a couple seconds
<apteryx>is (@@ ...) now prohibited in tests (due to Guile 3) ?
<leoprikler>bandali: Now I am
<leoprikler>apteryx: Yep, Guix uses declarative modules.
<drainful>Is there a guix command to get the store path of a package?
<apteryx>drainful: guix build package
<raghav-gururajan>leoprikler Doubt! When use a particular source in package definition, if any of the source files contains non-free or unlicensed files, we should use that source, correct?
<raghav-gururajan>*when we use
<nckx>*should not use?
<raghav-gururajan>*should not use
<leoprikler>You patch the origin, so that no unfree sources exist even in `guix build -S`
<nckx>raghav-gururajan: It's accpetable to remove (all, even ‘unused’) offending parts in a source snippett.
<drainful>apteryx: I see. That makes sense, thank you. Is there a way to get a specific output from the build command?
<leoprikler>if it's not out, you can | grep output
<raghav-gururajan>nckx I see. So if there is tarball that contains 90% files that are free and 10% files are unlicensed/non-free, and if we use that source with snippets to remove non-free parts, where will that 10% be stored in the users system?
<leoprikler>if it is, you-ll have to do something like $package-$version$$, where $$ is a literal $ (end of line)
<leoprikler>Nowhere, that's the point.
<leoprikler>We don't use non-free sources in guix.
<raghav-gururajan>leoprikler I am confused. Based on what you are telling, we should only use a source that contains 100% free parts correct? But nckx mentioned something about snippets to remove non-free parts.
<leoprikler>If you use snippets as nckx says, you'll be left with a modified version, that contains 100% free parts.
<apteryx>drainful: guix build will list them all. You could grep the result.
<raghav-gururajan>leoprikler So in that case, the unmodified source is first downloaded, then patch applied to modify the source, correct? What happens to the unmodified source?
<drainful>Thanks for the help.
<apteryx>you're welcome!
<raghav-gururajan>* patch ---> snippets
<leoprikler>not sure if it's gc'd immediately or remains somewhere in the store, but either way it is not used and not returned by any guix-related command
<raghav-gururajan>I see. Thanks!
<vagrantc>pretty sure it stays in the store, like when building linux-libre, you end up with several linux-libre-VERSION.tar.* in the store ... i presume some are the cleaned sources and some are the originals
<raghav-gururajan>vagrantc I see. Anyway, why would linux-libre needs cleaning?
<vagrantc>the linux-libre package in guix downloads upstream linux tarball, and then applies the linux-libre patches and scripts to do the cleaning
<raghav-gururajan>Oh...
<raghav-gururajan>I thought it was using linux-libre sources
<raghav-gururajan>We might as well can do that right?
<vagrantc>i think it was a while ago, but sometime in the last year or so switched
<vagrantc>raghav-gururajan: "might as well can do that"?
<raghav-gururajan>Damn poor grammer xD
<vagrantc>it gives guix the freedom to update a minor point release before the linux-libre folks get around to it
<vagrantc>raghav-gururajan: so poor i have no idea what you were getting at :P
<vagrantc>since the patches and scripts for linux-libre rarely need many changes between point releases
<raghav-gururajan>HAha.
<vagrantc>at least, that's my understanding
<raghav-gururajan>Wait a sec. So if linux-linux haven't got around a minor point release, that means their patches to deblob are not ready yet, correct? Then how come guix can use that patches when it is not ready?
<raghav-gururajan>*libre-linux folks
<raghav-gururajan>I need coffee
<raghav-gururajan>"since the patches and scripts for linux-libre rarely need many changes between point releases"
<raghav-gururajan>Gotcha!!!
<raghav-gururajan>vagrantc I think we should stop using vanilla linux as a source in package definitions. Because, we showing the end user where the unmodified/non-free source is. This also *gives* opportunity to use that source without patches/snippets. This is bad, right?
<vagrantc>raghav-gururajan: you bring this up quite often
<vagrantc>i know in the founding of guix it was discussed with the fsf and rms and it was deemed fine...
<raghav-gururajan>vagrantc I don't know why. Whenever I work on pakages, this thing keeps bugging me like an OCD>
<vagrantc>linux-libre does it as well ... just waiting for linux-libre would be hiring out the dirty work to someone else
<raghav-gururajan>Ah I see. Was that discussion public? May the contents of that discussion could satisfy me. :)
<vagrantc>it's well before my time
<raghav-gururajan>Oh.
<vagrantc>libreboot also does the same sort of thing
<vagrantc>it's a pretty standard practice for free-software respecting projects
<vagrantc>*someone* has to do the sanitizing, if sanitized sources are to exist and be used as free software
<raghav-gururajan>Is it? I didn't know. I thought projects that distributes free software should not convey where to get the non-free software/source.
<vagrantc>to the user
<vagrantc>it doesn't mean you have to put filters on your web browser to censor the internet
<vagrantc>which has lots of non-free websites
<vagrantc>you have to not advertise to the end-user
<vagrantc>to not allow automated systems to sanitize otherwise free software would mean you just can never use that software
<raghav-gururajan>Hmm. Makes sense.
<raghav-gururajan>vagrantc Thanks!
<vagrantc>hope it sticks :)
<raghav-gururajan>I hope that too ;)
***apteryx_ is now known as apteryx
<leoprikler>raghav-gururajan: the opportunity is already there even without doing so. See the channel that must not be named.
<raghav-gururajan>leoprikler Yes, yes, I just got the clear idea. We can only control what we do (what we distribute), we cannot control what others do (what others do with what we distribute).
<terpri>the linux-libre project doesn't have pre-librified tarballs available for all versions (iirc they sometimes delete them to save disk space)
<terpri>which would be at least one reason to use the patches with upstream tarballs
<raghav-gururajan>I see.
<bricewge>Hello Guix!
<bricewge>How to install libc manual, for example to get `man exec` working?
<leoprikler>IIRC guix environment --ad-hoc libc info-reader
<leoprikler>s/libc/glibc/
<bricewge>leoprikler: It makes `info` works but not `man` unfortunately
*bricewge still using an inferior documentation reader
<terpri>bricewge, the man pages are (logically enough) in the man-pages package. i think glibc only has info docs
<bricewge>terpri: Thanks, it works! I though that man-db and gnu-c-manual was enough.
*kmicu wonders whether Guixers at FOSDEM have a good time.
<oriansj>kmicu: people can have a good time anywhere at anytime; or a bad time anywhere at anytime.
<oriansj>but generally people don't go to a thing that they hate or dread, unless they are forced by external circumstances. (Required for work, spouse demands, etc)
<leoprikler>"My spouse forces me to use free software against my will" would be an interesting light novel.
***nly` is now known as nly
<mbakke>kmicu: I have it on good authority (unfortunately not my own) that the 30-something Guixers are enjoying themselves. :-)
<kmicu>ヽ(*^▽^)/
<jonsger>nckx: https://gitlab.com/jonsger/Guix/tree/wip-master-powerpc64le
<nckx>jonsger: Thanks!
<oriansj>leoprikler: yeah and my wife could write it; probably end up calling it 50 shades of software freedom.
<leoprikler>"Your safe word must contain at least one capital letter, one number, and one non-alphanumeric symbol."
<oriansj>leoprikler: lmao ^_^
<dftxbs3e>I'll be at FOSDEM, couldnt make it to Guix Days
<jonsger>dftxbs3e: nice
<nckx>dftxbs3e: Greetings from the POWER9 hacking corner.
<nckx>In which I try and fail to bootstrap Guix on POWER and jonsger tries to remember how he did it.
<dftxbs3e>nckx, hah, are you there already?
<nckx>nckx: I'm at the Guix Days, unfortunately I won't be able to attend FOSDEM proper ☹
<dftxbs3e>nckx, run `docker run -it registry.gitlab.com/lle-bout/guix /bin/bash`
<dftxbs3e> https://gitlab.com/lle-bout/guix
<dftxbs3e>It's a container image that has a working ppc64le GNU Guix install inside it
<dftxbs3e>that install can't build GNU Hello, but it brings you to the point where you can inspect to make it work
<nckx>dftxbs3e: I already found the second link (thanks!), I'm trying to understand how to do this rather than ‘just’ run docker (which I don't have anyway).
<dftxbs3e>nckx, recipe: https://gitlab.com/lle-bout/guix/blob/core-updates/Dockerfile
<nckx>dftxbs3e: Oh, I did that already.
<nckx>Thanks.
<nckx>guix show hello works, guix build hello doesn't.
<nckx>But, I might be getting somewhere cross-building the binaries on my x86 box. Maybe.
<nckx>Cool, it's building something.
<kmicu>Do you have a POWER9 hardware there (e.g. on a Raptor conference stand) to deploy Guix on it? 😺
<jonsger>kmicu: yes
<kmicu>That’s amazing.
<dftxbs3e>nckx, just run: `guix build --target powerpc64le-linux-gnu bootstrap-tarballs` on my tree and then patch like I've done here: https://gitlab.com/lle-bout/guix/commit/b169acfb341ffeda68695f8de79f00f352afdddf
<nckx>dftxbs3e: That's exactly what I'm doing.
<dftxbs3e>Great!
<nckx>After the long-double-128 error and patching cross-base.scm to add it.
<Draven>Does anyone else have an issue with a lot of rust drv's takin a lot of time?
<Draven>My computer have been calculating rust drv's for the last 24H :/
<cbaines>wingo, here's the guile-fibers build failure: https://ci.guix.gnu.org/build/2145228/details
<cbaines>I've built it successfully, but also had it fail to build
<wingo>cbaines: tx!
<nckx>jonsger: /gnu/store/3cyrklgpakahjh342qpqg92r6n0dps9j-bootstrap-tarballs-0
<nckx>Wewt.
<isBEKaml_>Hi, I believe this is a pretty common problem - how do you write shebangs in your scripts?
<isBEKaml_>The path can't be some custom path, right? Or do we symlink to a well known path?
<nckx>isBEKaml_: #!/usr/bin/env bash
<nckx> /bin/sh will also work on most Guix Systems, but is less ‘portable’.
<isBEKaml_>nckx: Yes, that's what I wound up with, eventually
<nckx>isBEKaml_: Good, using /usr/bin/env is the current consensus amongst distroes.
***isBEKaml_ is now known as isBEKaml
<efraim>nckx: I can host them online if you need somewhere
<nckx>efraim: Er… whatzactly?
<efraim>The bootstrap binaries. I host the backup copies of the aarch64-linux ones and the WIP ppc32 and now wip Hurd ones
<nckx>efraim: Any advantage to you hosting them over me throwing them up on tobias.gr?
<efraim>nckx: not if you already have a spot for them
<nckx>Ah, OK. Thanks for the offer 🙂
<nckx>They're pretty trivial to build so I'd rather not share them at all. It's a bit early to get back-doored.
<nckx>s/build/cross-build/
<ioa>good morning
<nckx>Good morning ioa.
<mjw>hi guix room at guixdays
<smithras>mjw: hello!
<jfred>o/
<apapsch>How do filesystems in a operating-system relate to testing in a vm (or deploying via ssh)? Should I just assume there's a /dev/sda1? no reference by id?
<bandali>leoprikler, hey, sorry, had already passed out. i have a question about ‘building emacs packages using emacs-next’ that we discussed yesterday. let me know when would be a good time for me to ask
<leoprikler>Go ahead.
<bandali>great
<bandali>so, i made an attempt at it:
<bandali> https://git.sr.ht/~bandali/guix-mab/commit/e0c62280690ffc9e1195c2c827d2a1e05b3177e9
<bandali>but after adding “emacs-next-delight” to my manifest and installing it, it looks like it was built with emacs-minimal (which is 26.3) anyway
<bandali>am i missing something?
<leoprikler>I think substitute-keyword-arguments does not work here, because no such argument is supplied.
<leoprikler>Try adding the argument with (arguments `(,@(package-arguments p) #:emacs emacs-next))
<bandali>hmm, doesn’t it add it if it doesn’t exist? at least that’s what i think i saw happen in tests/utils.scm
<bandali>also, if we just add it like that, what about the cases where #:emacs already exists? will the second instance of it (which we add) be used, or will the duplication be problematic?
<scmguru>Good morning, all.
<smithras>scmguru: good morning!
<scmguru>smithras: How are you this fine morning?
<leoprikler>it should not be a problem, the latter will override the former
<leoprikler>and no, this is not the same
<bandali>oh?
<bandali>how so?
<smithras>scmguru: I'm learning a lot at guix days :)
<leoprikler>the test supplies a default value it seems
<leoprikler>try #:emacs _ emacs-minimal
<scmguru>There's a Guix day?
<itsme[m]>is there a way to set proxy settings in guix? seems that the only way is on the command line
<itsme[m]>i mean, proxy settings in chromium
<itsme[m]>not guix
<bandali>leoprikler, hmm, i see, will try that. there’s also an interesting use of it in the guile-emacs definition where they supply a new list on the fly. any reason to do it that way? (add #:parallel-build? and #:tests? there)
<leoprikler>looks cleaner than the alternative I'd assume
<bandali>what would be the alternative?
<leoprikler>(#:kwd _ something?)
<bandali>ha, so kinda like what i’m trying to do?
<leoprikler>yep
<bandali>cool cool
***coldpress_ is now known as coldpress
<bandali>thanks, so adding the emacs-minimal default helped. now i’m bumping into an issue with the name of the generated autoloads file for the package, where it has the “next-” prefix
<bandali>guess i’ll have to look into the emacs build system again
<mfg>Can someone explain where the android-ndk-build-system sets the src files for a given package?
<bandali>leoprikler, so the culprit seems to be package-name-version->elpa-name-version from (guix build emacs-build-system). guess i could override that for myself in (bandali packages emacs-xyz) ?
<mfg>Because i can't find any reference to the relevant variables LOCAL_SRC_FILES and LOCAL_SRC_FILES_linux
<NieDzejkob>How can I check which package in my profile propagated a dependency?
<guixy>Hello guix!
<guixy>I'm running the package manager on a bananapi. It's been slower than ever since switching to guile 3. What is the commit before they switched?
<wingo>seems we don't have rr packaged
***ng0_ is now known as ng0
<leoprikler>bandali: you'd have to override the phase if I'm not mistaken
<bandali>hmm. yeah a simple overriding of package-name-version->elpa-name-version in my module doesn’t seem to have helped
<NieDzejkob>guixy: 8234fe653e61d0090138cbd4c48d877568355439?
<joshuaBPMan>Hey debian! I've got a question for you. Which is "better": 1) Install Wordpress on debian via the Wordpress package ya'll provide....OR downloading the wordpress source code directly and using that?
<NieDzejkob>(that's the commit when they switched)
<guixy>Thanks
<joshuaBPMan>sorry wrong channel.
<bandali>leoprikler, can i “override”/“modify” a phase? or would my best bet be deleting the phase and adding a new one instead of it?
<leoprikler>there is a replace IIRC
<guixy>ttfn
<NieDzejkob>Having a weird segfault on guile-git: https://paste.debian.net/1128499/
<bandali>cool, ty
<raingloom>hey, could someone help me debug evolution? i finally have some time to dig deeper into it but i could use some help.
<raingloom>it doesn't show any of my emails but it does seem to successfully download them through POP. i tried using my existing config in a VM, but when i copied it over it just ignored it and showed the setup wizard.
<mfg>Does anyone know a decent Tutorial which explains how to write a parser in guile?
<raingloom>it's not a font issue either
<raingloom>mfg: idk if there are tutorials but you should probably look into parser combinator or PEG libraries.
<mwette>mfg: Can you be more specific? Guile comes with PEG and LALR parser generators; I have written a separate LALR parser generateor
<mfg>i want to update the android tools. Since android8 they are using .bp files instead of makefiles. those files have a JSON-like structure. i need to parse them and (maybe) construct makefiles out of them.
<mfg>i thought this was a better way than hardcoding everything
<mwette>guix search guile-json
<mfg>it is not json it is similar to it. https://android.googlesource.com/platform/build/soong/
<mfg>but maybe this should be solved in a completely different way idk
<mwette>saw that; maybe start with that or https://github.com/johnwcowan/guile-json/blob/master/json/parser.scm, which is 300 lines and fix to handle the different keys
<mwette>oops, right link is https://github.com/aconchillo/guile-json/blob/master/json/parser.scm
<mfg>i also found this: https://groups.google.com/forum/#!topic/android-building/fkqKIMpbjmM
<mfg>so someone already tried to update those packages ...
<rupicapra>Hello
<NieDzejkob>o/
<mfg>Hi
<pkill9>hi
<gnutec>What up! :P
<rupicapra>My system update is taking like 18hours now, building multple rust's
<gnutec>rupicapra: You have to do this another day.
<gnutec>rupicapra: You have to do this another day.
<dongcarl>Hey all, did people decide on when and where for the dinner?
<rupicapra>Gnute
<rupicapra>Oh ok
<rupicapra>I was a but surprised coming home and seeing it
<gnutec>rupicapra: I wait to upgrade another day when "sudo -E guix system..." doesn't work.
<rupicapra>I get my laptop is old but it's not THAT old
<gnutec>My notebook is a i3 with 2GB and is OK!
<rupicapra>Aha!
<rupicapra>I knew I was safe
<gnutec>Need to go!
<NieDzejkob>rupicapra: Do you have substitutes enabled?
<bandali>leoprikler, so this is what i did: https://git.sr.ht/~bandali/guix-mab/commit/6f83bdcd3bb3715d53083551ef8b08ce072e0264
<bandali>but it doesn’t seem to have helped, and the build still fails as before
<bandali>and here’s the build log: https://paste.sr.ht/~bandali/2bc52074f832db56c2e5a44ff496536f8084b887
<leoprikler>apart from the naming issue, could this be a bug in delight itself?
<leoprikler>wait wtf?
<leoprikler>what's with this code quoting?
<bandali>hmm?
<leoprikler>the let inside the arguments seems really out of place
<leoprikler>especially if you already have to construct the name earlier on
<bandali>i don’t follow. i’m not using any of the three let-bound functions for the package name though ?
<leoprikler>you don't, but what you're doing is even worse
<leoprikler>because you already need elpa-name to construct name, but you compute it in a way that you have to repeat your steps
<bandali>is that the issue here?
<bandali>(to be very clear, this is my first go at this, and by no means is this great code)
<mehlon> https://github.com/NixOS/nixpkgs/issues/75669
<mehlon>here's a semi-convenient way to run Guix on nixos
<bandali>leoprikler, ^
<leoprikler>How did you manage to make the same error TWICE?
<leoprikler>And how did I let you do this?
<bandali>i don’t know, maybe i’m stupid? or maybe because i’m trying to juggle like 5 other tasks at once
<bandali>to be clear, you didn’t help with any of the let-bound functions, that’s my doing/stupidity
*apteryx thinks guix deploy is amazing
<bandali>leoprikler, can you give me some concrete feedback now?
<leoprikler>I've managed to fix most of the build-system related stuff, but emacs-delight still won't build.
<leoprikler>As I already assumed, that appears to be an emacs thing.
<leoprikler>I'll look for another library to try.
<apteryx>leoprikler: could you please cool down a bit. You're coming off as aggressive.
<dongcarl>I’m at great town square, where did everyone end up for dinner?
<leoprikler>Okay, it appears as if the (file-exists-p generated-autoload-file) fails, even though generated-autoload-file is let-bound
<leoprikler>Which is a weird way to fail, but it means we'll have to figure out something for that
<leoprikler>(or perhaps its another file-exists-p that fails, checking)
<lucky_guy>Hi all. anybody know what is the module (#g549 #)? https://pastebin.com/bevbrvBj
<raingloom>isn't '#' some kinda number syntax?
<leoprikler>bandali: try http://paste.debian.net/hidden/e74e0242/
<leoprikler>nope, that's garbage
<leoprikler>more accurately, it's likely some internal reference being spilled out instead of the thing that it should refer to
<leoprikler>bandali: as with emacs-next you ignored the case, where phases are unbound
<leoprikler>hence there was no modification of the phase
<leoprikler>the (commented) code I've pasted fixes that and adjusts the path correctly, but it still fails at generating the autoloads because that's an emacs bug
<raingloom>i know i've asked this before, but is Evolution broken for anyone else? i deleted all its configs and reconfigured it manually and it still refuses to show my mail.
<leoprikler>it's not broken for me
<raingloom>hmmm. what wm/de? i'm in Gnome right now.
<mwette> # is special read syntax; it's used for numbers quoting symbols etc That pastebin error does not make any sense. #~ is used for g-expressions; no clue what #g might mean
<raingloom>it works in a fresh Gnome VM
<leoprikler>GNOME as well
<leoprikler>However, my gnome has some additional inputs, such as evolution and evolution-data-server
<raingloom>the gnome (meta)package?
<leoprikler>yep
<raingloom>hmm, looks like i have it propagated from jami
<mfg>what does makefile syntax target: prereq := value mean?
<leoprikler>it's target: VAR := value
<thomassgn>could someone test my manifest? I'm getting errors like: http://dpaste.com/1X3ZYEE Here's the manifest https://notabug.org/thomassgn/guixsd-configuration/raw/master/usr-pkg-manifest.scm
<thomassgn>I have wcalc installed and upgraded after guix refused my manifest...
<bandali>leoprikler, i see. so the main two issues were: 1. me forgetting '%standard-phases for #:phases, and 2. emacs-next not generating autoloads correctly
<bandali>do you know more about 2? and if it’s a reported bug?
<leoprikler>I'm working on 2 right now.
<leoprikler>Basically, the issue is, that autoloads is not loaded and the variable is hence set incorrectly.
<mfg>leoprikler: so this sets a rule local variable? or what does it do?
<leoprikler>mfg: you guessed it
<mfg>ty
<leoprikler>thomassgn: could you rewrite this in terms of specifications->manifest? or perhaps simplify this by not resolving packages in such a way?
<leoprikler>btw you can do guix package -m manifest1 -m manifest2 -m manifest3 and all will be merged into a single big manifest
<leoprikler>I currently use the following to build my profile: `find ~/.config/guix -name 'manifest*' | sed -e 'i -m' | xargs guix package`
<bandali>leoprikler, i see, thanks. please let me know what you find
<leoprikler>bandali: I've sent a patch to the ML, waiting for the bug number
<leoprikler>And it's here, https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39375
<bandali>leoprikler, great, ty; will check it out shortly
<thomassgn>leoprikler: the '(packages->manifest (map (compose list specification->package+output)' is what specification->manifest is defined as in gnu/packages.scm Already tried it, gives me the same result.
<leoprikler>perhaps, but one of them is significantly nicer to read
<thomassgn>I could also write them out plain, but I'd have to add a bunch of module imports, I find this easier. Though just now it's become harder... :)
<thomassgn>haha. Yes. The spec->manifest requires an import though. :) I'll try again with it.
<leoprikler>You can try splitting it up into multiple files as I already showed you. That keeps imports per file minimal in my experience.
<thomassgn>yea, I might just have to do that. I just don't understand why this does not work anymore, been using it for a while now without problems.
<leoprikler>Did you edit it lately?
<leoprikler>or would this file still work with an old version of guix?
<bgardner>Good afternoon guix; I'm trying to add guile-json to my system packages and getting weird conflict errors ("guix system: error: profile contains conflicting entries for guile-json") that are new to me. Any advice to resolve this?
<terpri>bgardner, guile-json might conflict with guix itself, according to https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39313
<bgardner>terpri: So says the error message, yes. Let me read that and come back
<bgardner>terpri: This bug report seems to hint that "guix" is an installed package in the user's profile. I'm calling 'guix system reconfigure' with guile-json added to the package section, and I take that to be a different use case, no?
<bgardner>terpri: Although possibly a distinction without a difference, I guess
<mwette>Given a package is there a way to find it's guix package spec (in Scheme)? I get a hit from "guix search bytestructures" but I need the #:use-module part to add to my own package spec.
<dctrud>Hi guix - had an interesting question from Compute Canada about an issue where they use Nix userspace and are running Singularity on HPC cluster
<dctrud>Was wondering if anyone is using Guix in the same kind of setup as they describe with Nix here: https://archive.fosdem.org/2018/schedule/event/computecanada/
<bavier>mwette: 'guix search' will output a "location" field that can be transformed straightforwardly into a scheme module name
<dctrud>Compute Canada is using Lmod _and_ Easybuild on top of Nix, on top of CentOS
<mehlon>hey y'all
<Drakonis>hey y'all.
<bavier>dctrud: reminds me I have an lmod package I've been meaning to submit
<mehlon>I'm actually running Nixos right now but I'm using linux libre which surprisingly even has wifi on my device
<mehlon>so thats sweet
<pkill9>mwette: there is "specification->package" in gnu/packages.scm if that's what you're lookign for
<pkill9>looking*
<mehlon>anyway.... I have this crash using chromium: https://bin.privacytools.io/?3078f81b2a299764#aiSa3iWv/qmobAbNGzyF07tIL9ZL1ZEquIAYPgoPIvM=
<mehlon>[6100:6100:0131/223850.981095:FATAL:platform_font_skia.cc(97)] Check failed: InitDefaultFont(). Could not find the default font
<dctrud>bavier: ahh interesting
<Drakonis>updated your fonts?
<mehlon>not sure how to do so
<Drakonis>fc-cache -fv?
<Drakonis>no question mark
<mehlon>I feel like I've had this exact conversation before
<dctrud>bavier: what's the use case of having lmod vs using environments? build packages from source into arbitrary dirs and expose as modules?
<bavier>dctrud: if you haven't already, see https://hpc.guix.info/
<bavier>there are several blog posts and papers regarding Guix in the sciences
<mehlon>but no one mentioned the word deja vu before me so it's probably not a glitch in the matrix after all
<pkill9>what did you say?
<Drakonis>no such thing as a glitch in the matrix
<Drakonis>the human brain is just weird
<mehlon>ah of course... silly me..
<dctrud>bavier: yeah - I've read through that periodically. My background is an HPC admin in academia (biomedical field).
<mehlon>Drakonis: did fc-cache -fv but same error still.. I should mention I installed chromium with guix but am running NixOS
<Drakonis>right
<bavier>dctrud: some people have build processes that are run outside/on top of guix/nix that produces modules for end users
<Drakonis>then you might want to follow a different guide
<bavier>dctrud: neat
<Drakonis> https://guix.gnu.org/blog/2019/running-a-guix-xfce-desktop-on-centos-7/ the principles should be similar
<dctrud>bavier: fair enough, I guess if you have nix/guix base, easybuild making lmod module then you cover more ground in terms of applications available
<mehlon>good point, maybe I need to get some fonts with guix first
<bavier>yeah, kindof a crutch thing until everything has guix packages :)
<dctrud>I'm one of the developers of Singularity these days. Just trying to puzzle out where containers come into it also for people who commit to this type of stack
<mehlon>huh... I mentioned the matrix and now youre talking about singularity eh? hmm...
<dctrud>I won't talk about the exact issue Compute Canada have with singularity here, as it's related to non-free things.
<mehlon>Drakonis: thanks it worked. I just had to install font-dejavu and thats all
<mehlon>maybe I'll install font-liberation too.. it sounds very... freeing
<Drakonis>dctrud, discussion is fine
<Drakonis>only steering people towards it isnt
<mehlon>it's not like a taboo or anything :3
<mehlon>ok I know I'm starting to sound crazy but I just realized that my issue that gave me deja vu was solved by installing... deja vu.
<mehlon>it can't all be a coincidence
<Drakonis>heh
<Drakonis>dctrud, i figure it has to do with HPC hardware such as nvidia?
<Drakonis>the main folks are at fosdem right now
<mwette>bavier, pkill9 : I typed "guix repl" followed by ",use (guix packages)", but guile3.0-bytestructures is not defined. Should it be?
<mwette>^ this after "guix search bytestructures" reports package w/ name guile3.0-bytestructures and location guix/pacakges.scm:880:11
<bavier>mwette: uff da, no, it's defined in (gnu packages guile).
<bavier>The location must be thrown off the the use of 'package-for-guile-3.0'
<mwette>bavier: it's there
<pkill9>mwette: it's not in guix/packages, if you run `guix edit guile3.0-bytestructures` it returns you to a function used to generate the package
<bavier>I thought we had fixed that behavior
<mwette>Thanks!
<bavier>mwette: if you want, a bug-report might be nice
<mwette>bavier: will do
<Drakonis>dctrud, what's the details
<bavier>mwette: thanks! :)
<bandali>bavier, do you have a minute? was wondering if you had a chance to have a look at my emacs-xyz patches?
<bavier>bandali: not yet, but planning to tonight. sorry for the delay
<bandali>bavier, gotcha, no worries, and thank you
<nckx> https://www.tobias.gr/guixchan.html
<bandali>they should be fairly straightforward and easily mergeable
<bandali>nckx, i see i broke top 20! :p
<nckx>Someone asked me today how #guix has grown over the years. I don't know if we can know that retrospectively, but boy can I run useless Perl scripts on the logs!
<lfam>nckx: These "random" quotes... 😂
<leoprikler>guixchan sounds kawaii
<Drakonis>probably a good time to reset the most referenced urls
<nckx>Oh, yeah.
<Drakonis>sanitize it and get rid of the links from the bots
<nckx>Let me censor those as is our want.
<nckx>Done.
<bavier>aw darn, just missed the top
<bandali>> nckx is either insane or just a fair op, kicking a total of 5 people!
<leoprikler>random quotes "what's this code quoting?"
<nckx>bandali: Trick question, I'm both.
<leoprikler>s/this/with this/
<bandali>nckx, i always believed in you
<mwette>bavier: bug #39377
<mehlon>oh, guixchan? I think there was a cute anime version of guix somewhere, let me find it
<dctrud>Drakonis: sorry, got called away. It is due to NVIDIA stuff
<Drakonis>somehow it isnt surprising.
<mehlon> https://linuxreviews.org/GNU_Guix
<mehlon>there it is
<Drakonis>linuxreviews lol
<dctrud>They have Singularity on a CentOS host where people use Nix environments, and Singularity uses ldconfig to find libs which may be in odd places
<nckx>‘Linux’ ‘reviews’.
*nckx → bed for 4.5 hours of sleep, thanks for believing in me.
<nckx>I remain a real boy for another day.
<dctrud>But they need the CentOS ldconfig for that... not the nix one
<mehlon>so. immediate unanimous action to change the official Guix logo to that?
<dctrud>Easy workaround make sure you don't have Nix PATH when you run Singularity installed on CentOS... but there was an ask for a config option
<leoprikler>mehlon: That's Suika from Touhou, though.
<mehlon>oh
<mehlon>I apologize and for this slip up I shall retire effective immediately
<dctrud>I was just curious how people are, if at all, using containers if they've committed to Nix/Guix environments to work in
*mehlon it's a 'The Good Place' reference
<Drakonis>nix/guix have containers that pull from the store
<dctrud>Yeah in this case they appear to be needing to routinely run Singularity containers that aren't anything to do with their Nix setup
<bavier>dctrud: apparently some will produce singularity images with guix to be shipped off to a singularity runtime elsewhere
<bavier>dctrud: 'guix pack --format=squashfs <packages>...'
<dctrud>bavier: yeah, that's what I'm aware of. Here they are running Singularity images on the systems that have Nix envs on though
<leoprikler>"The GuixSD distro uses the guix package manager (it is like APT in Debian) which is the best package manager ever, dealing with gazillions of file versions without squinting."
<dctrud>not creating them to ship places without the reproducible envs
<leoprikler>Well, at least they have accurate, if somewhat outdated, information 😉️
<dctrud>I guess it's covering the base of people who want to singularity run docker images, and not interact with Nix envs
<Drakonis>i'm not sure if linuxreviews is supposed to b satire or serious
<Drakonis>be satire or serious
<mehlon>well it's not satire
<mehlon>it's just a bit of an interesting site, like 9front's main page
<leoprikler>I also like the 10 most used words on IRC: package there build would think system should about could which
<mehlon>I imagine vsauce reading this like an actual sentence
<mehlon>I do like how linuxreviews always has kpop images for all their reviews
<Drakonis>the commitment is strong
<Drakonis>much like dedoimedo
<Drakonis>dctrud, that setup is heckin complex
<Drakonis>holy moly, a five layer setup.
<dctrud>Yeah, it's a lot of layers
<dctrud>"holy moly" were the exact words I used in a company chat :-)
<Drakonis>heh
<Drakonis>doing hpc without this kind of setup would be so good.
<rekado>I’m perpetually struggling with the Guile API for derivations and monadic values.
<rekado>I find it terribly difficult to see the type of a value
<dctrud>Drakonis: I found myself buying some Infiniband cards on ebay the other day, so I'll no doubt play at that with Guix. Heh.
<dctrud>Not sure a Ryzen desktop and older Dell Optiplex count as HPC though :-)
<Drakonis>typed guile next :v
<rekado>often the comments or docstrings are confusing because they call something “derivation”, but actually it’s a monadic value
<rekado>yeah, I’d love to have either type annotations or more magic
<bavier>dctrud: >= 2 nodes counds
<rekado>I also find mlet, mapm, mbegin and the like to be kinda annoying.
<dctrud>bavier: It'll be nice to have to mess around with. There are many things I don't miss about being in an HPC group, but some of it was fun
<rekado>the idiom (with-store store (run-with-store store …)) also isn’t very pretty
<rekado>I wonder how this could be improved
<Drakonis>i hope that's in the books with post 3.0 guile
<Drakonis>fosdem funzies
<rekado>I’m trying to make the GWL use an inferior Guix, and it’s been driving me mad