IRC channel logs


back to list of logs

<raghavgururajan>Ah I see.
<roptat>mh, what's the correct linking order for static libraries? should I put dependencies first, or dependents first'
<steggy[m]>👋 I'm using fish shell, and to clear the screen it wants 'tput' from ncurses for clearing the screen. I _could_ just add to my path, but that seems brittle and "unguix" if I'm understanding things correctly - especially given that ncurses is a required input, it feels like it should just be exposed(though, not as a propagated, because I don't want to pollute stuff). Do I have that right/am I possibly missing something obvious?
<nckx>Hi steggy[m]! I just tried ‘guix environment --pure --ad-hoc fish -- fish’ and it clears the screen just fine, but I don't use fish. Is tput really required? When?
<nckx>Or maybe it's loading some file behind my back that pulls tput back into the environment.
<steggy[m]>Yeah, wonder if `which tput` resolves for you
<nckx>I really don't know the first thing about fish ☝
<steggy[m]>but, it might also be my weirdness with using vterm in particualr
<steggy[m]>s/particualr/particular and that playing with fish/
<nckx>bash: tput: command not found
<nckx>which: no tput in (/gnu/store/ms63nd256hqp6c92xb90ffi84mqzgwcn-profile/bin)
<steggy[m]>ah okay, so probably a quirk of my config; sec
<nckx>Hm or wait, maybe it's something about my environment.
<steggy[m]>huh, actually
<steggy[m]>can you `which clear` ?
<nckx>I didn't include ncurses so I won't have clear.
<nckx>If I include ncurses, I'll have tput :)
<nckx>How are you clearing the screen?
<steggy[m]>ah duh, good ol guix environment pure
<nckx>There was something amiss in my window. In a new one (wish I'd saved the old one but oh well) it does fail: ^L complains that it can't find ‘clear’ indeed.
<nckx>Not tput though.
<nckx>But same diff.
<steggy[m]>yeah, okay, that makes sense
<steggy[m]>Yeah, I changed things to tput because I was doing something different in my particular config
<steggy[m]>but either way, you need ncurses
<nckx>What was ‘unguixy’ about installing ncurses?
<the_tubular>It's not emacs :)
<steggy[m]>Well, my initial reaction was "well I'll just add ncurses's bin to my path"
<nckx>Is that a roundabout way of saying ‘install ncurses’ or…?
<steggy[m]>and that seems like badthink compared to "the package should just have the thing, what if they get out of date/versioned(which, like, okay, 0% chance with ncurses, but it's the principle!)
<steggy[m]>* of date/versioned"(which, like,
<steggy[m]>well, so I definitely do have ncurses in store, but given that ncurses is an input to fish, there should be some way to let fish know about it without polluting the rest of my env with whatever version of ncurses fish wants, right?
<steggy[m]>Again, could be totally off base, I only started guix a month ago and still trying to get used to the mindset :)
<the_tubular>same steggy[m]
<nckx>The Guixy way would be to patch fish to invoke ‘clear’ by its full /gnu/store/… file name instead of relying on $PATH at all.
<steggy[m]>Yeah! That's what I was thinking - something that made fish look at the one installed in the input'd ncurses
<nckx>Your reasoning is correct steggy[m], I just had to read it twice (◍•ᴗ•◍)
<nckx>fish seems to have the same hard requirement for ‘uname’, by the way.
<nckx>It barfs during startup because it's not in $PATH.
<steggy[m]>👍 Honestly appreciate the super prompt response/walking through it :)
<steggy[m]>oof, I do have uname somehow in my path
<nckx>Which makes ‘Welcome to fish, the friendly interactive shell!’ under a wall of errors quite amusing.
<steggy[m]>not sure what put's coreutils there - how could I find out?
<vikanezrimaya>if I remember correctly, uname() is a function in C. Why does fish even bother with calling a subprocess for it?...
<nckx>steggy[m]: /gnu/store/hk5ypq06jh0f65jzxv8q918wcyjzp018-fish-3.2.2/share/fish/functions/
*dstolfa is a ksh/bash user
<steggy[m]>Okay, well, this seems like a fun first-patch possibility to get my toes wet
<nckx>vikanezrimaya: My sentiments exactly, but that might not be the attitude taken by people writing a ‘friendly interactive shell’ in the first place, I dunno.
<vagrantc>i've toyed with fish now and then and been pleasantly surprised by it ... but never enough to toss out decades of old habits
<nckx>steggy[m]: That would be great! I was going to take a look at patching clear, but it's good that you protect me from myself. I really should be doing real work.
<steggy[m]>:) This way I can prevent folks from doing lots of real work by asking questions here :p
<dstolfa>vagrantc: that's what i thought about zsh and fish too. they look fancy, but i have habits of very plain looking shell (usually with no colors), full of orange text.
<dstolfa>i really don't need all the friendly & interactive features.
<steggy[m]>Honestly, having dipped my toes with fish, it's nothing too fancy/much better than bash, and I definitely dip to bash to get complex loops up
<vagrantc>if i were just getting used to using shells today, i'd totally consider fish
<steggy[m]>but day to day, it is very friendly
<nckx>steggy[m]: Since you're new (welcome!) here(?), just want to point out one pitfall: you might be tempted to use wrap-program here to add ncurses & coreutils to $PATH, as is done elsewhere in Guix. You can't do that here: fish is a shell, and a shell silently munging PATH to invoke a different coreutils than the user might've installed is a big no-no.
<steggy[m]>Gotcha - yeah, that would be very uncool to do
<nckx>Worse… it would be… unguixy. 🦇
<steggy[m]>I'm thinking of just adding to ```(add-before 'install 'embed-absolute-paths... (full message at
<vikanezrimaya>IIRC `bashInteractive` in Nix uses ncurses and other C libraries to do stuff like resetting and also getting hostname
<vikanezrimaya>I wonder why fish doesn't do that in guix
<vagrantc>most often the answer to such questions is "nobody thought to try" :)
<nckx>steggy[m]: For unrelated reasons related to cross-compilation, you can't simply use (which …) either. Instead use (lambda* (#:key inputs #:allow-other-keys) (substitute* "file" (("clear") (string-append (assoc-ref inputs "ncurses") "/bin/clear"))) …))
<nckx>Modulo typos :)
<steggy[m]>ty, I was definitely gonna use which, but grabbing from the inputs is what I actually want
<nckx>vikanezrimaya: Why ‘in guix’? Isn't this just how fish is written?
<steggy[m]>I think fish just declares "we have a dependency on curses/ncurses, figure it out" and assumes it'll have things in path
<maximed>steggy: Maybe avoid (which "nroff"), use search-input-file (on core-updates) or (string-append (assoc-ref inputs "nroff") "/bin/nroff") instead
<maximed>it's required for cross-compilation
*nckx gnorfs.
<maximed>(but otherwise, when compiling natively, (which "stuff") works fine)
<steggy[m]>Okay - to be clear, that's in shells.scm right now, but I could definitely change that
<maximed>oh, I haven't read what nckx wrote
<steggy[m]>* change that(or, my shells.scm at any rate)
<maximed>i.e., nckx already wrote that
<steggy[m]>ah, gotcha
<nckx>maximed: Is search-input-file the brave new labelless world thing?
<steggy[m]>What's the cross compilation deal? That some OS's won't have which?
<maximed>nckx: It's the labelless thing, yes.
<nckx>No, that (which …) will return the native host binary, not the one that will be run on the target.
<maximed>There's also the ‘labelful’ #$(file-append (this-package-input "stuff") "/bin/stuff")
<nckx>So if you're on x86 compiling for arm, which at build time will (correctly) return the x86 ‘clear’, but you don't want that to be used by your arm fish.
<nckx>maximed: Will that still work in future? I still need to get up to speed with the changes over the summer :)
<nckx>Cool changes, daar niet van.
<steggy[m]>Gotcha, and then substitutes won't just naively work?
<maximed>nckx: assoc-ref + string-append still works
<nckx>OK, cool.
<maximed>it's just a bit tedious to write, and 'assoc-ref' might be a bit scary to newcomers or something
<steggy[m]>Out of curiosity - my current way of playing with this is just "put the package I'm messing with in a file, do things, `guix package -f $FILE` - is there a more clever way of doing this kind of iterated change-test looping?
<maximed>The input labels are becoming less prominent to ‘the user’, but internally they are still there, and do not seem to be disappearing anytime soon
<nckx>steggy[m]: The procedure substitute* will work, if that's what you mean, and it will successfully embed a file name to clear, and Guix will track that (x86) as a dependency of (arm) fish and make sure its present on the system when you install fish, it just won't run and fish will fail in a probably ugly way at runtime.
<nckx>* that (x86) ncurses package
<steggy[m]>Oh sorry, I meant substitutes like a package substitutes, but gotcha that guix will track the arch's correctly
<maximed>steggy: I recommend "guix environment --ad-hoc -l $FILE"
<maximed>such that the whole profile doesn't need to be rebuild
*nckx AFK.
*dstolfa sighs
*nckx lols.
<maximed>Instead, "guix environment ..." builds a temporary profile, containing only the listed packages
<maximed>nckx: (about search-input-file): Additionally, search-input-file raises a ‘nice’ error if the file doesn't exist
<maximed>instead of type errors with unclear backtraces
<maximed>it's origins were from before the labelless thing actually, IIRC
<bsturmfels>I'm just attempting to build coreboot on Guix, but it's complaining about a missing Ada compiler "gnat". Does anyone know if this is available in Guix under another name? I can't seem to find it by grepping the sources
<bsturmfels>build warning also suggests it might be called "gcc-ada"
<roptat>bsturmfels, I think gnat has a bootstrapping issue: it's partially written in ada
<bsturmfels>ah, thanks roptat
<oriansj>roptat: guix also has a Ada compiler written in C, which could be used to bootstrap gnat if I remember correctly. which was the original Ada compiler used in GCC, so it does have a valid bootstrap path in GCC. I can't however speak to if someone has done that work yet.
<iskarian>sneek, later tell excalamus: I don't think you need to combine the packages; just making a package for plover-python-dictionary and then installing both that and plover in your profile *should* work
<sneek>Will do.
<iskarian>(and then for dictionary packages, you would make plover-python-dictionary a propagated-input)
<excalamus> I'll try that
<sneek>excalamus, you have 1 message!
<sneek>excalamus, iskarian says: I don't think you need to combine the packages; just making a package for plover-python-dictionary and then installing both that and plover in your profile *should* work
<excalamus>working on defining plover-python-dictionary atm
<roptat>oriansj, oh I didn't know, thanks :)
<roptat>\o/ I have a working adb from android 11!
<roptat>now... let's try and package fastboot :)
<bsturmfels>great stuff!
<roptat>I'm just a bit worried about the fastdeploy thing in adb, it pushes a jar file to the phone, and I'm not 100% sure that jar file will actually work ^^'
<roptat>but I don't know how to trigger that
<excalamus>how do I learn about sneek commands?
<iskarian>"/msg sneek help" I believe
<xd1le>hi guix
<nckx>Hi xd1le.
<iskarian>Huh. Why doesn't (search-path (package-native-search-paths python)) give me a PYTHONPATH?
<iskarian>I definitely have other packages in my profile with the /lib/python3.8/site-packages dir
<the_tubular>I'm looking to do a firewall with guix, anyone has any idea on how that would work ?
<apteryx>iskarian: I had a similar encounter recently in the ansible 4.4 package
<apteryx>perhaps there's some sort of circular reference at the top level? I didn't get it.
<iskarian>There is the PYTHONPATH/GUIX_PYTHONPATH split in core-updates, but I don't understand it
<apteryx>that's unrelated though, no?
<apteryx>if you have questions about GUIX_PYTHONPATH perhaps I can answer them, as I was the implementor ;-)
<apteryx>note there's a better, commented version in review on guix-patches of
<apteryx>it fixes an isse found by mothacehe
<iskarian>apteryx, ah, yeah, you're right, it should be unrelated. I haven't even looked into it yet to be honest, so I won't make you explain from the beginning. I'll get to it eventually :)
<civodul>Hello Guix!
<abrenon>hi guix
<xd1le>o/ hello
<muradm>ehlo guix
<qzdlns[m]>morning guix
<RuZzz>How do I move the gnu directory to another partition? Maybe there is some example of a config file?
<RuZzz>I had created a symlink /gnu on /pms/gnu
<RuZzz>To configure grub for a kernel, I had set path like this '(hd0,gpt6)/gnu/store/...-libre-kernel'
<RuZzz>My config
<RuZzz>Maybe there is a way to specify paths more abstractly?
<civodul>RuZzz: hi! in general, you should leave /gnu at /gnu
<civodul>it can live on a separate partition, and Guix System will generate the right "search.file" GRUB commands, tho
<RuZzz>I would like the /gnu and /nix directories to be on one separate partition /pms
<raghavgururajan>Hello Guix!
<seeg>hello, I'm new to guix. Am I missing something or is nodejs yarn not present there? Thought it was kinda a basic package :)
<lilyp>seeg: you tell me how "basic" yarn really is:
<seeg>hm, ok
<brendyn>seeg, I believe there is a blog post somewhere of someone attemping to calculate how many dependencies are required for basic js packages and it went in to the several thousands, including older versions of the same package
<seeg>well, nix does have yarn etc
<seeg>(I don't mean to accuse people here :) )
<seeg>I just wanted to try out guix with my dev project and I'm stuck at the basics :)
<brendyn>It's a great question to ask
<brendyn>There is one important reason there isn't much javascript stuff in Guix yet and it comes down to how crazy we all are. The nix package just downloads the yarn release tarball and installs it. You could do that in Guix too. But in Guix we are putting a lot of effort in to ensuring all packages can be truely built from source. Many javascript packages are not truely "source", but include code that has been generated or minified. We want to
<brendyn>package those dependencies so we can generate everything in Guix. When you look at how many dependencies there really are, it begins to spin out of control
<dhruvin>Hello guix! I have updates on sourcehut builder image and a follow-up question.
<dhruvin> developers told me to continue using the repository field of build manifest for channels (even though they are not perfect fit).
<muradm>i have a function that has one argument, that one argument can be either record of some-type or (program-file ..). i can easily test if passed in argument is record by some-type?, for program-file, i see from code that it is also record, but its program-file? is not exported, why?
<muradm>how can i check if passed in thing is a thing returned from (program-file ?
<lilyp>muradm: we typically use (ice-9 match) for record matching within guix, hence the predicates themselves aren't exported
<seeg>ah, ok brendyn, is there a way then to do it like nix?
<muradm>lilyp: hmm... you suggest me to write (match (($ <program-file ...))) ? but wouldnt it fail, if that match applied to <some-type> ?
<lilyp>you can have a separate match clause for your <some-type> record, no?
<brendyn>seeg, I'm sure there is a way with a lot of work. I think you need to package nodejs
<lilyp>nodejs itself is already packaged
<muradm>damn... like this? (match (($ <program-file> ....) (...program-file-body ...) ($ <some-type> ...) ( ... some-type-body ...))) ?
<muradm>missied paranthesis i think above, but idea is clear i think.. :)
<seeg>I meant to replicate what you wrote: "The nix package just downloads the yarn release tarball and installs it. You could do that in Guix too."
<lilyp>muradm: yup
<muradm>lilyp: thank :)
*muradm face palm :D
*muradm realized how much things can refactor/simplify
<dhruvin>Okay, now I guess I can continue: Since guix channel specification may have various optional options, e.g. branch commit first-signed-commit ..., I came up with What do you think?
***dekenevs is now known as kitzman
<dhruvin>Something along the lines of
<seeg>another thing is I see haskell stack is missing which is also somwhat a "basic" package :)
<muradm>dhruvin: hi, personaly i liked previous version, where you just had channel in scheme.. :) but for the sake of curriosity, why do you go with properties like multiline string, instead of straight yaml?
<muradm>maybe it would be easier to map yaml node to channel? also more user friendly and clear syntax
<dhruvin>'s manifest restricts that
<dhruvin>I too wanted to map channel specification to yaml, but devs asked to use string only.
<dhruvin>muradm: For example, alpine image uses space separated options.
<muradm>pity.. why then you switched from channel in raw scheme?
<muradm>i think i missed that part
<dhruvin>muradm: About the previous version, devs asked to keep the format simple, something bash can parse.
<dhruvin>(Although, I'll be using scheme to parse it anyway.)
<dhruvin>*by parse I mean operate on
*muradm what a cruel world ...
<muradm>why do they need it in bash?
<dhruvin>muradm: I'm not sure, let me ask them if it's strictly necessary.
<muradm>dhruvin: i mean you are in yaml controlling scheme, why introduce 3rd syntax, 2 is not enough?.. :)
<dhruvin>Update: It's not necessary, if I can make it work, we can have scheme inside yaml.
<dhruvin>(Given I'll be using a shepherd service to handle everything in scheme.)
<dhruvin>muradm: Thanks for your inputs. Just to be clear, you were talking about this right?
<dhruvin>muradm: (Ignore the substitutes part in this paste)
<muradm>dhruvin: yes, it is more concise than properties, for user just a copy paste, in my opinion better :)
<dhruvin>I have two options to choose from.
<dhruvin>1. Evaluate said scheme code and verify that it returns a valid channel
<civodul>mbakke: hey, good news: i reinstated static NSS support in glibc, for use by guile-static:
<civodul>it took me quite a bit of trial and error until i decided to just get all the relevant commits
<dhruvin>2. Just paste the code in ~/.config/guix/channels.scm as is and fall back to guix pull's error handler.
<civodul>i also tried using glibc 2.31 and .34, but that doesn't work, due to symbol versioning and all
<muradm>dhruvin: the other day some one was pointing to sexp->channel function for reference
<muradm>^^^ gnu/services.scm
<dhruvin>that function requires the sexp to be of type channel-instance (and not channel)
<mbakke>civodul: oh my, nice work, thanks! :-)
<dhruvin>muradm: Also, (make-channel-introduction) is a function that'll return a channel-introduction when evaluated. (openpgp-fingerprint _) will have to be evaluated as well.
<muradm>dhruvin: yes, but you could use similar logic in your guile scripts to avoid plain (eval-string "...") for security reasons
<civodul>mbakke: yeah, it's just frustrating that fixing a single issue on the branch took this long
<civodul>anyway, we're making progress!
<dhruvin>muradm: Yes, I wasn't going to use eval-string. For that I'll have to import (guix channels) in gexp of the shepherd-service.
<dhruvin>muradm: (guix channels) depends on (git) which cant be brought in the module closure in straight-forward way. (at least that's what I've been told)
<muradm>muradm: there is such piece of code
<muradm>may be could be helpful if you won't call functions that use exports of (git)
<dhruvin>muradm: I think this can do. I'll have to learn a bit more about it before I can understand what's going on in that scheme code.
<dhruvin>muradm: Thanks.
<raghavgururajan>Folks! Please let me know your thoughts on GTK4 patch-set v10 ( :)
<attila_lendvai>what's the deal with the guix wiki? will there ever be a dedicated one?
<dhruvin>muradm: Doing this will help implement validation of user-input scheme code. I'll still have to prepend said channel specification to %default-channels in channels.scm for guix pull to work.
<dhruvin>muradm: Are there any upsides to validating user input before adding a new channel, if guix pull is called immediately after doing so anyway?
<muradm>dhruvin: i suppose if you are going to call "guix pull" from script it is possible to trust that it will fail any way on corrupt channel definition
<dhruvin>muradm: The reason why I asked that is because I'm a bit stuck here. I'll either have to pattern match sexp (which is prevented by the requirement of evaluation of make-channel-introduction and openpgp-fingerprint), or will have to eval the string anyway to check for a valid channel being returned.
<muradm>dhruvin: what i understand now, is you just want to configure supposedly container you are in which is for one time use, right?
<dhruvin>muradm: Yes
<muradm>and you are not going to do complex stuff, just call "guix pull" "guix install"
<muradm>there is "guix package --export-channels"
<dhruvin>muradm: can exapand complex stuff?
<muradm>read "guix package --export-channels" read your input, make a single list and write to /etc/guix/channels.scm may be
<dhruvin>muradm: Yes, but that uses channel->code (to output channels.scm compatible code). I need code->channel.
<muradm>dhruvin: months ago when i started writing shepherd services, i wrote one, that was interacting with guix, i.e. it was defining dependencies, making derivation and starting it :) it was pretty slow, but showed the power of "scheme every where" :)
<dhruvin>muradm: In our case builder's users will be adding channel to the build manifest and the builder's shepherd service will be adding them (supposedly after validating/verifying) to ~/.config/channels.scm.
<muradm>that is complex :)
<muradm>dhruvin: if you are going to add ~/.config/guix/channels.scm, i don't think that you need %default-channels
<muradm>ah sorry
<muradm>yes you need that
<dhruvin>muradm: okay
<muradm>dhruvin: why not just put %default-channels ?
<dhruvin>muradm: It's the default when system boots.
<dhruvin>muradm: It gets additional channels added by users at configuration time.
<muradm>(append (list manifest-channel1 manifest-channel2) %default-channels) => ~/.config/guix/channels.scm
<dhruvin>muradm: That's pretty much the code. (Although I use cons there.)
<dhruvin>muradm: cons'ing recursively is just breeze, since won't give me all channels at once (this is a known issue)
<roelj>Hi Guixers! Is there a reason why we don't have a gnutls 3.7.x package?
<muradm>dhruvin: wrapping with cons* or (apppend same thing, can be done as much as you want :)
<dhruvin>muradm: I get channels one by one in order. I replace %default-channels with (cons (channel ...) %default-channels) and everything works magically.
<dhruvin>muradm: I thought about cons* and append and they won't work as easily as this does.
<muradm>dhruvin: that is also a way :)
<dhruvin>muradm: * I should have written as beautifully as cons does :)
<muradm>dhruvin: (thumb up) :D
<dhruvin>muradm: Thanks for your help and inputs. I'll get back to working on the image and hopefully have it merged by the weekend.
<raghavgururajan>lilyp and leoprikler: Same?
<raghavgururajan>I mean, change of nicks?
<muradm>dhruvin: welcome.. :) although i did nothing :D
<EdLin>I'm still a beginner at this, what does cons* do?
<EdLin>("this" being guile)
*raghavgururajan is happy that rust toolchain finished building :D
<EdLin>raghavgururajan, people here were mad at me a bit when I complained that compiling the kernel here was unusually slow at 8 minutes. (on other systems it's under 3)
<EdLin>operating systems that is
<EdLin>they said for them it was a half hour. :P
<EdLin>16 cores is nice....
<raghavgururajan>EdLin: I see. I am using X200T. So I'll leave it to your imagination. ;-)
<EdLin>raghavgururajan, what is x200t?
<raghavgururajan>device name.
<mbakke>dhruvin: I'm not yet sourcehut user, but at work we use the 'guix-install-action' on GitHub to generate reproducible container images, does your work mean I can do similar things on sourcehut now? :-)
<raghavgururajan>2 cores @ 1.86GHz
<EdLin>raghavgururajan, what architecture? I'd need to know IPC to compare, though sounds like an older laptop.
<EdLin>is this one of the older systems that's libreboot compatible? I wouldn't mind having libereboot compatibility.
<raghavgururajan>EdLin: The first post here ( has my system config.
<EdLin>I also liked that POWER workstation that had free firmware, but it was not only too expensive for me, an exploit mitigation made it perform a lot worse.
<EdLin>raghavgururajan, it says there "tablet". It's a two in one? :)
<raghavgururajan>EdLin: Yep, but its primarily a laptop. It has wacom on the screen, so tablet as well.
<EdLin>my laptop's a two in one.... I like having the functionality for drawing with a stylus.
<EdLin>wacom, yes, mine has that also.
<raghavgururajan>Yeah, same.
<EdLin>oh, core2duo....
<EdLin>it's nice that it can run libreboot though.
<EdLin>what makes newer hardware tend to be incompatible with that?
<EdLin>back to my earlier question, what is the difference between cons and cons*?
<EdLin>cons makes pairs, right?
<dhruvin>mbakke: Yes, and you can do even more. You get a shell into your actual build vm if anything goes wrong and you want to inspect it yourself.
<EdLin>I couldn't get the VM feature of guix working here.
<EdLin>I must be doing something wrong
<mbakke>dhruvin: oh, that's really nice :-) is it possible to override %default-channels too, e.g. to use a specific Guix commit?
<maximed>EdLin: there is no difference between cons and cons* when only using two arguments
<maximed>(cons* x y ... tail) --> (x y ... tail)
<dhruvin>mbakke: Yes, Just don't add any channels to repositories section of build.yml. And have the first task of your build pipeline to setup channels.scm the way you like.
<maximed>(cons* x y ... tail) = (append (list x y ...) tail)
<EdLin>I still don't understand. I tried learning scheme using sicp, but it uses a lot of algebra and I don't have a college education.
<maximed>and I wasn't mad at you
<EdLin>ok. :)
<maximed>cons ‘enlarges’ a list by a single element
<dhruvin>mbakke: All tasks are shell scripts and its cat "(list (channel ...) (channel ...)" > "~/.config/guix/channels.scm" away
<maximed>(cons 'x '(some stuff)) -> (x some stuff)
<mbakke>dhruvin: cool :-) I've been meaning to try SourceHut a while, this is a good incentive :P
<maximed>cons* enlarges the list by multiple elements
<maximed>(cons* 'x 'y 'z '(some stuff)) -> (x y z some stuff)
<raghavgururajan>> what makes newer hardware tend to be incompatible with that?
<raghavgururajan>EdLin: This page ( has some good details. :)
<dhruvin>mbakke: I'm glad you found it interesting. :) I plan to support images for several architectures for long-time. Do let me know of feature requests once you try
<maximed>append pastes two lists together: (append '(x y) '(z w)) -> (x y z w)
<maximed>or three: (append '(x y) '(z w) '(0 1)) -> (x y z w 0 1)
<maximed>or more lists
<EdLin>raghavgururajan, pretty depressing, if the newer systems never support libreboot, it means after the caps decay too much on most older systems, the libreboot project will be nearly dead.
<EdLin>except for the fork that's on Chromebooks I guess.
<EdLin>(caps decaying is why you don't see a lot of 20+ year old hardware around)
<EdLin>I should say "degrading" rather than "decaying", electrolytics are not radioactive. lol
<apteryx>Is anyone here interested in Cling? The C++ interpreter developped by CERN.
<raghavgururajan>EdLin: Thats where osboot ( comes in. Also, for libreboot, there is scope for non x86 systems like ARM, OpenPOWER etc.
<civodul>apteryx: not really "interested" but i vaguely considered packaging it some time ago, as an example kernel for Jupyter
<apteryx>OK! I got it working in the "build everything at once (patched LLVM + patched Clang + Cling plugin), but when attempting to build it from prebuilt (patched) LLVM & Clang, linking to LLVM libraries fail
<apteryx>not sure why
<EdLin>raghavgururajan, openpower had a lot of promise, but then hackers discovered an exploit whose mitigation requires constant flushing of L1 cache, garanteeing no commercial application for that architecture until a redesign occurs.
<EdLin>maybe ARM will be the answer tho
<raghavgururajan>On all versions (POWERn)?
<raghavgururajan>I see.
<EdLin>older ones don't have it, but those don't have commercial application because they're obsolte.
<apteryx>civodul: my last attempt:
<roptat>mh, during cross-build, why can't I access native-inputs?
<apteryx>if you go back to 2 commits earlier (the non-fixup one), Cling builds and runs fine
<roptat>I use "clang" in the native-inputs, but during the cross-build (assoc-ref inputs "clang") returns #f
<maximed>roptat: (assoc-ref native-inputs "clang")
<roptat>oh there's a native-inputs key?
<civodul>apteryx: nice; so the main issue is that the version that works ends up rebuilding everything, right?
<maximed>roptat: Yes, though only when cross-compiling
<apteryx>yeah, it'd be neater to have the components build separately (which their CMake build system seems to support); it makes it easier to experiment at the level of the Cling package
<apteryx>which the Cling build system*
<qzdlns[m]>If I'm running =inherit= thorugh some =operating-system= definitions, but how should I deal with services? Getting missing core (e.g =networking=) when calling =operating-system-user-services=, but duplicated core (e.g shepherd root, system) services when I just take all base services with =operating-system-services=
<apteryx>civodul: another question I had was whether LGPL2.1+ applies as a the "combined work" license; LLVM is Apache 2.0, which Cling (LGPL 2.1+) links to.
<civodul>apteryx: ah, i suppose LGPL applies to the combination
<civodul>annoying that there are too many false negatives when running "guix weather -c10" on core-updates
<roptat>ah but I need a cross-clang
<asgas>Hello. Blender in the repos is at 2.92. The latest LTS is 2.93.4 and the blender package needs to be updated.
<roptat>can I select different inputs depending on the target?
<roptat>I have a cross-clang procedure, so I'd like to do something like (if target (cross-clang target) clang)
<asgas>Who do I talk to if I want or need a package to be updated?
<civodul>asgas: hi! if you're impatient, you can try "guix install blender --with-latest=blender" and report back here
<maximed>roptat: (if (%current-target-system) (cross-clang ...) clang)
<maximed>the 'inputs' and 'native-inputs' fields are thunked, so that should work
<civodul>asgas: this will build the latest version on your machine, as per: (can take a lot of time)
<maximed>i.e., (package (inputs STUFF) ...) is internally translated to something like (package (inputs (lambda () STUFF)) ...)
<asgas>My hardware really sucks, so it's just not practical to compile from source. I only ask for whoever maintains the repos to switch to the LTS branch rather than stable for blender.
<civodul>asgas: packages are maintained collectively, and we'd happily welcome you on board
<civodul>if you could try upgrading it and report how it went or send a patch, that'd be perfect
<maximed>asgas: "--cores=1" and "--max-jobs=1" reduces memory usage
<asgas>So this isn't like say debian to where there is an assigned maintainer?
<maximed>in case you mean "little RAM" with "hardware sucks"
<maximed>asgas: sometimes there are de-facto maintainers for some packages, build systems, importers ...
<civodul>asgas: no; the project purposefully chose to not list specific names under each package
<civodul>in practice there are still affinities, of course, but there's no notion of "ownership" in the sense Debian has
<asgas>If I ever get around to making a package for 2.93.4 I'll be sure to submit a patch. Guix seems to be more reliable and trustworthy than some strangers ppa for ubuntu.
<AleQu[m]>Ni! Hi all ... Any tips on running cups besides adding the service to config.scm ? The web interface loads but the admin page doesn't. In the logs trying to load /admin shows several connection attempts and then "max clients reached".
<roptat>I'm building llvm, and it's interesting to see a mix of [ 6%] and [100%] in the logs ^^'
<muradm>i have a function that receives argument, which i normally pass result of (program-file ....), for documentation of that function argument, would it be correct to write "A gexp->script like executable to use as ..."?
<asgas>This doc here is all I need to make a package right?
<zimoun>why «guix copy --from=jack /gnu/store/69a8g84jxz8kld94ii9l7yk9m1m5pg5k-r-minimal-4.1.1» returns «guix copy: error: implementation cannot deal with > 32-bit integers»? What do I miss?
<roptat>asgas, you might also want to have a look at existing packages to see how we write them in general
<asgas>I think this patch is very trivial. Just update the version and the SHA256 hash and we're good.
<maximed>zimoun: is that store item > 4GB?
<maximed>maybe check with "du --total /gnu/store/..."
<roptat>asgas, oh in that case, it'll be extremely easy indeed :)
<asgas>How am I to get the base32 hash? I am using sha256sum right now.
<maximed>"guix hash the-tarball.tar.gz"
<roptat>or guix download if it's a tarball, too
<maximed>"guix download https://.../the-tarball.tar.gz" should also work
<roptat>if it's a repository, you'll have to get the same commit and use "guix hash -rx ."
<maximed>asgas: even simpler: you could try "./pre-inst-env guix refresh -u blender", and let guix update the version and hash to the latest for you
<maximed>"guix refresh" always choses the latest though, not LTS, which might not be what you want here
<zimoun>maximed: “guix size” returns 1.2GiB, so the store item is really less than 4GB, I guess.
<asgas>What's with the = sign at the end of the base32 encoding?
<qzdlns[m]>why might =guild= be throwing me an warning like =failed to create path for auto-compiled file "/home/samuel//.guix-profile/bin/guild"=? filesystem permissions?
<EdLin>guix upgrade seems to be upgrading nearly everything, is there a reason for this?
<maximed>EdLin: what do you mean exactly?
*maximed runs guix package -u
<EdLin>it's downloading nearly everything.
<maximed>what's ‘everything’ here?
<maximed>More specifically, what is it downloading that you think it shouldn't need to?
<EdLin>it's downloading gigabytes of packages
<EdLin>I have limited bandwidth, I can't reinstall my whole distro every day
<EdLin>hm, guix package -u was more reasonable.
<maximed>if the packages that are being downloaded are out-of-date, and there's a new version available, then it is expected that it would be downloaded
<EdLin>I guess I'll use that rather than upgrade
<maximed>EdLin: "guix upgrade" is an alias for "guix package -u"
<maximed>If you run "guix upgrade", interrupt it, then run "guix upgrade" again, by then the first "guix upgrade" will already have downloaded some things, so the second doesn't need to
<maximed>I _think_ I know what you're referring to
<maximed>"guix package -u" had some output like ‘the following packages will be updated: [...]’, right?
<EdLin>I didn't see that, it must have scrolled out of my terminal window
<maximed>it has output like "package X will be updated from version 1.2 to 1.4"
<maximed>but also "package X will be updated (because dependencies changed)"
<asgas>I need someone to look over this modified script to see how it looks before sending it upstream to guix. It's blender 2.92 updated to 2.93.4
<maximed>EdLin: next time you run "guix package -u", could you capture the output?
<maximed>"guix package -u |& tee the-output"
<roptat>asgas, something's wrong I can't see your paste. could you use instead?
<maximed>asgas: the base32 string is suspiciuous, it should be lowercase
<maximed>asgas: did "guix build blender" work?
<maximed>asgas: To test only the 'source' field, you can do "guix build --source blender"
<maximed>how did you compute the base32 field?
<maximed>it's also much loner than I'd expect
<maximed>* longer
<asgas>To be perfectly honest, I'm away from my GNU/Linux machine right now. So I'm unable to use guix for the time being. I have an SHA256 hash checker and base32 program I used to get the base32. Sorry about that, if someone with guix access could double check, that would be great.
<excalamus>EdLin, guix package -u=REGEXP, there's also --do-not-upgrade=REGEXP, for updating specific packages or excluding others
<maximed>The output from "guix hash ..." is the base32
<roptat>asgas, that's definitely not a base32 string
<roptat>asgas, guix download told me it's "1ckz91hj0b5gzbf0534vfd09050sbvq7s8chrg20mbykyaf43hg5"
<asgas>Then that would be the correct hash because I did it wrong.
<rndd>hi guix! is it possible to manage guix (pull channels, install packages, etc) using guile repl instead bash?
<rndd>didn't found notes related this topic
<maximed>rndd: what are you trying to do exactly?
<maximed>Are you writing an application using guix as a library?
<rndd>maximed: for example - pull channels from .scm file
<maximed>Not every API is documented in the manual.
<maximed>But you could use 'guix-pull' from (guix scripts pull)
<maximed>(guix-pull "--help") --> print the help output
<maximed>(guix-pull) --> pull
<maximed>(guix-pull "--channels=the-scm-file.scm")
<maximed>Not sure if that works.
<rndd>i see
<rndd>so i can ,use (guix scripts whatever)
<rndd>i will play with it
<rndd>thank you
<maximed>I'm wondering if anyone has tried to make a graphical interface for guix, other than emacs-guix
<maximed>using the gtk+ bindings for guile or something
<rndd>well, first of all there must be actual gtk+ bindings for guile
<maximed>rndd: there are gtk+ bindings for guile
<rndd>Latest News June the 2nd, 2017
<maximed>I've tried it out before, and seems to work well
<excalamus>are there Qt bindings?
<excalamus>I'm not finding any
<maximed>there's also guile-gi
<apteryx>maximed: there was something yes, authored by dannym
<apteryx>I haven't tried it
<maximed>That seems nice.
<maximed>I'll try it out later
<maximed>if it works well enough, maybe it can be added as a package to guix and recommended somewhere in the manual
<rndd>meh, i should definately spend more time on guix
<rndd>btw, why not use already existing gui's for different tasks?
<rndd>for example, for installation process there is anaconda
<rndd>of something used in fedora
<maximed>this has been considered before, with Gnome-Software
<excalamus>I'm trying to debug a definition for the python package
<excalamus>"python-plover-dictionary". This is a Plover plugin.
<muradm>lfam, bricewge: hi, #49969 v6 submitted :)
<excalamus>I have done `guix import pypi -r plover-python-dictionary > plover-python-dictionary.scm`
<excalamus>I want plover-python-dictionary for Plover v4 (which is the available in Guix). Per the Plover community, the plover-python-dictionary plugin should be compatible with Plover v4. I remove the autogenerated python-plover definition in plover-python-dictionary.scm because its for plover v3. I update references for "python-plover" to be just "plover". I add the definition name at the end of the file. The result is
<excalamus>I create `guix environment plover` then run `guix build -f plover-python-dictionary.scm`. The build fails. The log says it cant find source for plover-python-dictionary:
<excalamus>any idea why?
<maximed>the source is not found because the source isn't on ‘’?
<maximed>Maybe the URL needs to be changed
<excalamus> The URL came from the guix import call. I guess it might not be right
<excalamus>Changed where though? The plover-python-dictionary.scm has (uri (pypi-uri "plover-python-dictionary" version))
<excalamus>...which I would think resolves correctly
<excalamus>(it clearly doesn't)
<excalamus>maximed, I'm not sure how to confirm or deny whether it's on navigating there in my browser yields nothing.
<excalamus>for any part of that domain
<excalamus>and I don't see that path any where in pypi
<dstolfa>sneek: later tell rndd: as someone who's modified anaconda and has complex setups based on anaconda, i think that is a terrible idea. simple way to crash anaconda: have 2 disks with MDRAID metadata and watch anaconda drop you into the python debugger.
<sneek>Got it.
<excalamus>Looks like it's the back end for pypi, but it's not clear to me how they're connected
<pineapples>muradm: Hi! I just glanced through your greetd+seatd patchset and noticed that you moved the latter out of `freedesktop.scm' to `admin.scm' and that you also somewhat heavily modified the package recipe of `seatd'. In this case, should you be requested to make changes to v6 and sumbit v7, I'd like to ask you if you could remove my name from the copyright header in `freedesktop.scm' :-)
<podiki[m]>excalamus: not sure what is happening behind the scenes, but needs underscores in the filename (except before the version) in the url
<podiki[m]>then the url works you had in the error message
<podiki[m]> works for me
<excalamus>podiki[m], thanks
<muradm>pineapples: hi! hmm... i don't know about removing names from copyright, never done that :) may be i can move your name to admin.scm with the packages, but i'm not aware of such practice either... :) may be maintainers may comment on your request.. :)
<excalamus>I guess that means the URL is fine, that's god
<muradm>pineapples: but i tend to agree with you on keeping things tidy.. :)
<podiki[m]>not sure why the file is with underscores (not so in other packages?)
<excalamus>where are you looking?
<pineapples>muradm: I, too, have concerns if this is an appropiate practise, but I can abandon my right to the original `seatd' package recipe if this is required. I don't mind who holds rights to whatever I submitted to this project as long as the users of GNU Guix can benefit from it :)
<excalamus>may be it's grabbing from the line(uri (pypi-uri "plover-python-dictionary" version))
<pineapples>...and, of course, as long as the GPL3 license is enforced
<excalamus>yes, sir, that made a diffence
<mbakke>muradm, pineapples: it's common practice to move copyright headers with the associated code
<podiki[m]>excalamus: not sure what is happening, just checked a random package you were trying to build too (pyobjc-core) where the minus stayed a minus
<excalamus>failing elsewhere now
<podiki[m]>good luck! i've done just a few python packages, but there are tons of examples in guix to see things that need to be done
<excalamus>thanks, any suggestions? I've just been grepping broadly
<muradm>mbakke: thanks, what about removing?... :)
<pineapples>mbakke: Can my copyright header be just removed if I renounce my right to the original code and request that it's transferred to muradm?
<muradm>pineapples: you will need to issue a license, that will license that :D
<muradm>i noted, the moving of pineapples @ to admin.scm, since in the end of the day i modified what was there before.. :)
<podiki[m]>excalamus: I just look for errors I came across, like wrapping GI paths, or doing substitutes (patches). feel free to ask here when you hit something (though personally will be afk for a while, much more experience here than me)
<mbakke>muradm: not sure, there are precedents either way (leaving the original copyright notice intact + adding it on the new code location, and removing the original notice)...
<mbakke>pineapples: that's a good question, and I am not in a position to answer that :-)
<mbakke>the safest bet is probably to leave the original notice, and add it in the new location
<excalamus>podiki[m], thanks for sharing your experience. It's a nice sanity check
<pineapples>mbakke: I'd remove the original notice since there's no other work made by me in the original file besides the code that's now being moved. Anyway, thanks for your opinion!
<pineapples>/s/I'd/I'd also
<pineapples>But yeah, I agree this is the safest bet
<dhruvin>Correct me if I'm wrong here. I believe guix has rolling release model. It does not have support lifecycle like debian and ubuntu have. Right?
<maximed>dhruvin: Correct
<dhruvin>What's the difference between stable and latest? If I guix pull on 1.3 stable release will I get package definitions of latest?
<maximed>you'll get the latest
<dhruvin>I'm asking this in the context of sourcehut build image. Should I offer stable and latest variants? Since one can always pin their channels if they wish to.
<maximed>The difference between stable and latest, is that for ‘stable’, it is checked whether the installer works
<maximed>possibly some other differences as well
<dhruvin>maximed: That makes sense. I'll build/update guix images nightly. Nightly updates to latest release is fine, right?
<maximed>fwiw, ‘stable’ is updated irregularily, at each ‘release’
<maximed>dhruvin: What do you mean with ‘release’ here?
<maximed>Nightly update and latest release seem mutually exclusive
<maximed>release = 1.2.0, 1.3.0, ...
<maximed>latest (unreleased) version: the latest commit
<maximed>* version -> ‘version’?
<dhruvin>maximed: I'm sorry I meant nightly builds made for guix image.
<dhruvin>maximed: Let me rephrase
<dhruvin>maximed: There'll be a single guix image. It'll be replaced (updated) by latest commit of guix every night. Is this update frequency fine? Or should I update the image every week?
<maximed>that seems reasonable to me (‘every night’)
<dhruvin>maximed: I see 100 commits added between 2nd of the month and today. So nightly is fine, right?
<dhruvin>maximed: Okay
<dhruvin>maximed: Thanks :)
<maximed>dhruvin: Does do some kind of caching?
<maximed>That is, will it download guix from every time someone tells to build stuff?
<dhruvin>maximed: For packages?
<dhruvin>maximed: Yes it'll download those packages. It does not have caching.
<maximed>for the system image: <>
<dhruvin>maximed: Now that you mentioned it, I think it'll be a problem. I'll ask community about it.
<dhruvin>> for the system image: <>
<dhruvin>maximed: I'll look into it. Thanks.
<maximed>It would be nice if has some kind of caching proxy for substitutes
<maximed>presumably, has a lot of machines in close proximity, so caching could help a lot
<maximed>(caching substitutes)
<dhruvin>maximed: IFAIK they have their own repository for arch/alpine
<maximed>dhruvin: you might want to ask the sysadmins of the ‘official’ guix build infrastructure whether caching would be required
<dhruvin>maximed: Are you suggesting we set up a substitute server over at
<dhruvin>maximed: I'll email them about it.
<maximed>dhruvin: that's an option, if has the resources for that
<maximed>though I was thinking of a caching proxy
<maximed>(substitute server = server that builds substitutes & servers them)
<maximed>(possibly the serving and building is separated)
<dhruvin>maximed: Okay. I'll ask about both of these options. 1. Caching proxy and 2. substitute server.
<dhruvin>maximed: If I were to setup said caching server, do you have any pointers to resources where I can learn more about it?
<dhruvin>maximed: Or I can go thought the man pages of guix if this information is available there.
<dhruvin>maximed: *through *proxy
<roptat>fastboot \o/
<roptat>and adb, added yesterday: \o/
<roptat>still have to figure out a way to cross-compile libcxx and work on the importer as well as update to the latest android release
<maximed>dhruvin: I don't have pointers to setting up a HTTP caching proxy specific to guix
<maximed>a generic proxy should work
<dhruvin>maximed: okay
<iskarian>morning guix :)
<iskarian>excalamus, how's plover coming?
<hjklambda>Is there an easy way to "mask" packages? meaning they never touch my computer even if they are dependencies of other packages
<maximed>are you thinking of a specific package?
<hjklambda>I thought of maybe cloning the guix repo then remove the package definition, but that seems too much
<hjklambda>maximed: yes
<maximed>if they are dependencies of some package, then the dependency should be on the computer if the package is used, no?
<maximed>Unless they are optional dependencies
<hjklambda>yes it's mostly optional and if not there are probably build options to disable it
<maximed>hjklambda: there's "guix install ... --with-input=..." to replace inputs of packages
<maximed>but no option to remove inputs afaik
<maximed>I suppose it would be possible to implement --delete-input=PACKAGE
<maximed>but it isn't currently
<maximed>IIUC, these options are saved in the profile somewhere, so you wouldn't need to add them again at the next "guix package -i/u/..."
<maximed>hjklambda: what package were you thinking of?
<maximed>hjklambda: you want to remove "cups" from the inputs of packages?
<hjklambda>yes from all the packages I have installed
<maximed>it might make sense to split "" and the include headers into a separate output
<maximed>That way, gtk will only keep references to that output
<maximed>and not all of cups
<hjklambda>Or maybe make a dummy definition for cups and make mine override guix's
<maximed>(the /lib dir is only 1.6M)
<maximed>hjklambda: there is no mechanism for overriding packages
<maximed>(except (set! cups my-cups))
<maximed>hjklambda: Why do you want to remove "cups" from the inputs of packages?
<maximed>Is it space concerns?
<hjklambda>Im not currently using a printer and when I do it probably is not going to be using cups
<hjklambda>so i would rather remove it
<hjklambda>And if i knew how to do it I would remove other package's optional dependencies
<hjklambda>I want to make compiling from source have a little advantage since Im doing it anyway
<iskarian>hjklambda, you could make also make a dummy package with no output and then use --with-input=cups=dummy-package
<iskarian>However, I suspect it will break a lot of packages if they explicitly use the CUPS input and it's not just autodetected with ./configure
<nckx>Happy Monday, Guix.
<nckx>hjklambda: How do you print on Linux without CUPS?
<hjklambda>hmm, is there a way to track which package I currently have depend on cups, because there are things like gtk that depend on cups and other packages use it, so it goes package -> gtk -> cups, How do I remove a dependency like this?
<hjklambda>nckx: take a pdf file send it to printer using netcat
<maximed>hjklambda: guix refresh -l cups maybe?
<maximed>That won't find everything though
<maximed>because there are multiple variants of cups in guix
<nckx>hjklambda: Interesting, I wouldn't expect that to work on recent printers. Thanks.
<excalamus>iskarian, I'm running into problems and finding ways to resolve them. It feels like I'm making progress.
<excalamus>this is the latest script:
<excalamus>bombing out on error: Could not find suitable distribution for Requirement.parse('python-xlib>=0.16')
<iskarian>excalamus, that's good to hear! I found an issue with what I originally suggested. For some reason adding 'search-paths' for PYTHONPATH to plover doesn't actually give me a PYTHONPATH envvar in profile
<excalamus>it's looking for python-xlib
<nckx>Did you give it it it?
<nckx>*it to it, which is barely an improvement.
<excalamus>nckx, probably not :P
<iskarian>excalamus, you also have plover both in propagated-inputs and native-inputs :p
<iskarian>it should probably be inputs tbh
<iskarian>be in inputs*
<excalamus>good catch
<podiki[m]>speaking of python-xlib, I have an updated definition but also with a patch for a bug I was running into (failing on display matching)
<podiki[m]>I'm hoping upstream will fix it properly, as a bug was filed
<podiki[m]>the bug was reported in ubuntu a year ago, but maybe the python xlib people never saw it. easy enough to work around, but should be properly fixed
<hjklambda>iskarian: I think --with-input is what I want, thank you all for all the suggestions!
<iskarian>excalamus, you also won't need the other package definitions in that file since they are actually just dependents of plover
<iskarian>hjklambda, happy to help :)
<iskarian>OH! I figured out why PYTHONPATH wasn't working. I was using search-paths, but needed to use native-search-paths :)
<excalamus>iskarian: I figured. I'm not sure which are needed, so I figured I'd over shoot, get it working, then clean it up. I'd like to know how to find out which commands live where
<iskarian>excalamus, after you have that package working, you'll want to add `(native-search-paths (package-native-search-paths python))' to plover's definition so plover sees plugins
<excalamus>whoa! I might have a success!
<excalamus>iskarian: cool, tanks
<excalamus>dang need to head out for a bit. Will follow up later
<excalamus>(just when it was getting exciting)
<muradm>in "guix repl" there was ",help guix" now it is missing?
<nckx>excalamus: Go revel in your potential Heisenbergian succes. As long as you can't test it, it works!
<nckx>Oldest Guix I have handy is from May; no ,help guix.
<dstolfa>nckx: \o
<nckx>Hi dstolfa!
*nckx is I/O bound 😉
<nckx>I'll ping you.
<dstolfa>sounds good :).
<nckx>Of course…
<nckx>Backups, however, are good.
<dstolfa>nckx: though, maybe some prior releases don't?
<dstolfa>it would be good if those continued to work.
<nckx>This isn't Linux,® after all, which is mirrored about 's much as the bible.
<muradm>(let ((exp1 '())) #~(#$exp1)) fails with invalid expression input
<nckx>Works on its own in a REPL.
<nckx>I'm not doing anything with it, mind you, but that line alone returns fine.
<nckx>dstolfa: Maybe, who knows :) I don't.
<muradm>(let ((exp1 '())) (program-file "test" #~(#$exp1))) to be correct
<nckx>Who prints the error? guix build?
*nckx AFK a while.
<nckx>I can't get it to fail at the REPL but I didn't try to build it yet.
<muradm>yes, while building
<muradm>(run-with-store (open-connection) $1)
<muradm>wrong type to apply
<muradm>(run-with-store (open-connection) (program-file "test1" #~(exit)))
<muradm>wrong type to apply
<maximed> muradm: maybe (run-with-store ... (return (program-file ...)))?
<maximed>or (run-with-store ... (mlet ((progfile (program-file ...))) (pk 'p progfile)))
***sneek_ is now known as sneek
<raghavgururajan>maximed: Does v10 of GTK4 patch-set look good to you?
<maximed>I haven't looked at it yet
<maximed>for clould-providers -> for cloud-providers
<maximed>it seems ok to me
<maximed>Could you verify (find-files "//.desktop$") is correct?
<raghavgururajan>Yes, I checked the output files.
<maximed>Shouldn't this be (... "\\.desktop$")
<maximed>Otherwise, you're looking fo a file names //.desktop I think
<raghavgururajan>Oh the slashes
<maximed>IIRC, there is a phase for patching .desktop files
<maximed>not sure if it always works though
*raghavgururajan rebuilds gtk
<maximed>so the 'patch-desktop-files' phase might not be necessary
<raghavgururajan>Yeah, I am rebuilding without my custom phase.
<raghavgururajan>maximed: Yep, not required. Thanks! :)
<nckx>Someone tried to impersonate me whilst I was away: Last failed attempt from: guix! on Aug 29 17:04:02 2021 +0000.
<raghavgururajan>We now have GTK4. :D
<civodul>well done, raghavgururajan
<raghavgururajan>Thanks! Couldn't have done without the help from lilyp and maximed. :)
<vagrantc>efraim: so, debian's got riscv64 working on the sifive unmatched now (kernel, bootloader, and most packages) ... but it's notably missing the guix package :)
<vagrantc>efraim: i tried just applying a few patches on top of guix 1.3.0 a while back and had partial luck, but got stuck in the bootstrap ... i'm guessing you're targeting core-updates now?
<pineapples>I'd like my modified `myeetype' package to be grafted onto all installed packages that depend on `freetype'. How do I do that?
<vagrantc>wow definitely a "scratch your itch" niche system: dd7df191b6c8c3bbbece31b6946018dbaef553b4 gnu: u-boot-nintendo-nes-classic-edition: Make it actually boot again.
<lilyp>raghavgururajan: on which branch tho? :P
<jab>maybe I'm just being a moron, but I can't seem to compile the example gtk application for C...
<jab>example.c:1:10: fatal error: gtk/gtk.h: No such file or directory
<jab>I've got gtk+ installed...
<jab>gcc $( pkg-config --cflags gtk3 ) -o example example.c $( pkg-config --libs gtk3 )
<jab>Package gtk3 was not found in the pkg-config search path.
<raghavgururajan>lilyp: wip-gnome
<civodul>jab: the example you're looking may be a GTK4 example, whereas the command is for GTK+3
<civodul>(at first sight)
<jab>civodul: That's possible...but I don't think guix has gtk4 packaged yet?
<raghavgururajan>jab: I think pkgconfig files for gtk3 are in the format gtk+-3.0
<jab>ok...let me give that a try.
***xgqtd is now known as xgqt
<jab>raghavgururajan: I think you're right...
<jab>"pkg-config --cflags gtk+-3.0"
<jab>"pkg-config --cflags gtk+-3.24"
<jab>"pkg-config --cflags gtk+-3"
<jab>none of those work in the shell.
<raghavgururajan>jab: Btw, you can use gtk4 in wip-gnome branch.
<jab>raghavgururajan: that sounds like lots of work. Thanks for merging that by the way!
<raghavgururajan>jab: Try `guix environment --pure --ad-hoc gtk+ pkg-config -- pkg-config --libs gtk+-3.0`
<raghavgururajan>Or `guix environment --pure --ad-hoc gtk+ pkg-config -- pkg-config --cflags gtk+-3.0`
<jab>raghavgururajan: thanks.
<jab>I'm getting closer to figuring it out.
<jab>export PKG_CONFIG_PATH=/gnu/store/68fn9l1nxrjdxqpf3yx4gai7p18f82ja-gtk+-3.24.24/lib/pkgconfig
<jab>now pkg-config --cflags gtk+-3.0 is just complaining that pango was not found in the config path.
<civodul>jab: to hack on a GTK+ app, the easiest solution is probably something along the lines of: guix environment --ad-hoc gcc-toolchain gtk+ pkg-config
<civodul>that'll spawn a shell where all the relevant environment variables are set
<jab>civodul: that's true. It just annoys me that that's the correct solution. New users to guix would probably be confused...Why wouldn't just 'guix install gtk+' work? I'm not complaining. Just pointing it out.
<jab>Perhaps we should do something like:
<jab>export PKG_CONFIG_PATH=/home/$HOME/.guix-profile/lib/pkgconfig by default
<jab>that almost solves it for me, but now pkgconfig says it can't find xproto.pc
<jab>and thanks for the help Ludo!
<civodul>jab: another solution is to run "guix install gcc-toolchain gtk+ pkg-config"
<civodul>that has the same effect, once you've followed the hints it displays
<jab>civodul: I've got all of those installed...
<jab>I wonder why I ran into such difficulties.
<jab>export PKG_CONFIG_PATH="$HOME/.guix-profile/lib/pkgconfig:$HOME/.guix-profile/share/pkgconfig/"
<jab>that last line solved it for me.
<jab>Would it be ok if I try to make a patch that defines PKG_CONFIG_PATH in that way?
<jab>or is that not a good solution? Or is this a "feature" not a bug?
<Guest36>hey so I just installed Guix yesterday and now I'm getting this cryptic error "In procedure struct-vtable: Wrong type argument in position 1 (expecting struct):"
<Guest36>when running "sudo guix system reconfigure /etc/config.scm" I mean. I reverted my config.scm to a working version and the error stays