IRC channel logs


back to list of logs

<mirai>the kwarg naming can be improved, yes (strictly speaking it's not really kwargs since you can pass optional arguments or the “rest” argument)
<mirai>the multiple fields together can be performed with a "customized" base-transducer
<lilyp>fair enough
<mirai>it's not the full integrated SRFI-171 originally proposed in $THREAD but it's a step in the right direction
<lilyp>for your sheep, you have Emma, Franz and Mary either in the stable or on the ranch doing things (you decide what things)
<mirai>regarding the test for generic-ini
<mirai>the second value returned from a (with store …)
<mirai>do I need to do anything about it?
<mirai>or can I just ignore it and move on with the first value only
<mekeor>hello guix. i'm trying to package emacs-jinx but emacs can't find "emacs-compat" when being called in a phase. what's wrong?
<lilyp>mirai: I assume it will be garbage collected if you leave it alone, but do grep for similar code
<mekeor>adding these parameters to the invokation of emacs works as a dirty hack work-around: "--directory" (search-input-directory inputs "/share/emacs/site-lisp/compat-")
<mekeor>it seems like emacs has problems finding the compat library because it's in a nested directory.
<mekeor>i also tried adding "-f" "guix-emacs-autoload-packages" but it did not work
<mekeor>anyway, i'm gonna try to make it work with ugly hacks first
<mekeor>(this is my first slightly advanced package declaration)
<lilyp>strange, can you print out EMACSLOADPATH after expand-load-path?
<lilyp>it might be that unpack is too soon a phase, try another before build
<mekeor>oh yes, i didn't think about that, thanks :)
<mekeor>yes it is:
<mekeor>omg, it works!
<attila_lendvai>sneek: later tell civodul: respawn-service in shepherd doesn't seem to check whether the service is disabled or not. i got into a state where my service was stopped according to `herd status`, i also issued a `herd disable`, but the process is still running, and whenever i terminate it with a kill -TERM, shepherd keeps respawning it.
<sneek>Got it.
<ryan77627>Hey all, for those experiences with making package declarations, I have a question. I am attempting to build xdg-desktop-portal-hyprland so I can use it in place of wlr
<ryan77627>woops, sent that too early, one sec
<ryan77627>...wlr's portal, however after the main build phase, i need to build a secondary component. Is there a way I can `cd` using guile in the build environment? I'm already making a new build phase after the default one to build this secondary component and am planning on using a lambda, but would just running "cd" in it as well work? Not too sure the "proper" way of accomplishing this
<jackhill>ryan77627: yes, here's an example:
<jackhill>the chdir sticks between phases
<ryan77627>jackhill: Wow, you had that on lock and ready to go. Thanks, I'll take a look!
<jackhill>ryan77627: haha, I've had need of it as well :)
<jpoiret>ryan77627: doesn't wlr support hyprland as well?
<matto->newbie question: is there an example how to setup your .emacs-file, while using emacs-packages through the package manager, like guix install emacs-smartparens, and so on? On other systems I use (use-package ..), should I do that on Guix too?
<zamfofex>ryan77627: I was trying to package Hyprland the other way, but it seemed difficult, because it required some foundational Wayland and general GUI packages, and it seemed to need to rebuild a lot of stuff.
<zamfofex>the other *day
<zamfofex>Eventually I settled for bspwm and the “animations” fork of Picom, since those were straight‐forward enough to set up. 🙂
<mekeor>matto-: it depends on whether you want to use-package.el's :ensure feature, i guess
<mekeor>matto-: one approach is to just make sure that you have installed needed packages with guix. that's just fine.
<mekeor>matto-: another approach is this (rather experimental and uncommon) emacs package: which tells use-package.el to ensure that emacs packages are installed by installing them with guix (into an emacs-specific profile, by default)
<mekeor>personally, i don't use use-package.el anymore. i just start emacs, then use emacsclient. so, the performance benefits from use-package don't matter for me.
<matto->mekeor: thanks ! and in your .emacs, you still have your config for those packages? with (require ...) or something?
<jlicht>sneek: later tell csepp: Can you try clearing "./guile" in your guix checkout dir? I may have more cargo cult tips if that does not work :)
<sneek>Will do.
<ChocolettePalett>Btw, how should GNU/Guix users turn off their PC? Via halt or shutdown? Maybe poweroff?
<janneke>ChocolettePalett: there's no poweroff on my system? as to whether to shutdown or halt:
<janneke>$ readlink -f $(type -p shutdown)
<janneke>i guess you can safely choose any ;)
<ChocolettePalett>Ah, okay then, this sounds much less controversial than those opinions from the Internet
<ChocolettePalett>Thanks (:
<mekeor[m]>matto-: yes, with require
<mekeor[m]>ChocolettePalette: i use "loginctl poweroff", iirc
<matto>mekeor: thanks !
<HiltonChain[m]>zamfofex: I have packaged Hyprland in my channel. If you are still interested in it, here's the link: <>
<jpoiret>csepp: did you update your system and user profiles as well?
<jpoiret>we never managed to get to the bottom of this specific issue, most of the time upgrading all profiles would solve it. I think one library isn't in the shell and gets picked up from the system-wide profile, which is linked with an older libc
<Parnikkapore_m>I might be trying to package something that requires downloading two separate source tarballs. How do I do that?
<mekeor>Parnikkapore_m: wildly guessing, write a package for one source, and use it as dependency in the other package :D
<attila_lendvai>Parnikkapore_m, i think i've seen somewhere an origin entry in the inputs
<mekeor>it'd be nice if there was something like ripgrep for s-expressions
<janneke>Parnikkapore_m: with gexps this has become easier, grep for '#$(origin'
<Parnikkapore_m>I knew there's gotta be a really easy way to do it with gexps haha, thank you so much!
<f3n1x>hi guixers ! ... newbie here. I work with hugo web framework. I've downloaded it as a binary. Placed it into '/opt '. The /opt/ folder is in my $PATH by means of ~/.config/guix-home/.bashrc . When i run 'hugo' it doesn't work though . What am i missing ?
<f3n1x>thanks, thanks, thanks
<cbaines>f3n1x, normally this is because the binary has a hardcoded linker, which doesn't exist
<f3n1x>Oh... ah. Dunno what a hardcoded linker is... On the other hand, this setup is working in another machine, here at home. By the way, if i run '$whereis hugo' i get
<f3n1x>'hugo: /opt/hugo/bin/hugo /opt/hugo'
<f3n1x>Any hint is more than welcomed !
<HiltonChain[m]>f3n1x: As a temporary solution, you can build hugo locally and it would work.
<cbaines>f3n1x, you can see (and change the interpreter) with patchelf, e.g. patchelf --print-interpreter $(type -p guile)
<f3n1x>ACTION is gonna try to build hugo locally !
<HiltonChain[m]>cbaines: hugo is statically linked
<cbaines>HiltonChain[m], ok, the linker shouldn't be a problem then
<HiltonChain[m]>Oh, I made a mistake! Hugo has an extended builfd tag which requires CGO_ENABLED=1, variant with this tag is dynamically linked.
<zamfofex>Conversely, you can invoke the linker yourself!
<al1r4d>f3n1x: why?
<lw>How do I build `vterm` in Emacs, with guix?
<lw>-- The C compiler identification is GNU 4.3.1 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - failed
<lw>I get a compiler error
<lw>I'm trying to spawn vterm inside emacs. It asks me to build it
<lw>I was not successeful using the guix install emacs-vterm. I seem unable to use it inside Emacs
<janneke>lw: did you send a bug report?
<lw>i don't know if it's a bug. I'm uncertain of how I should use `emacs-vterm`. Currently, I'm using (package! vterm) to install it inside doom emacsen
<lw>doom emac*
<HiltonChain[m]>I just tried
<HiltonChain[m]>guix shell emacs emacs-vterm -- emacs
<HiltonChain[m]>and `M-x vterm` seems fine
<jlicht>lw: What does `guix shell --container emacs emacs-vterm', and then `TERM=xterm emacs' in that shell, do? Can you M-x vterm in that emacs?
<jlicht>ACTION is too slow at typing again :)
<lw>`guix shell emacs emacs-vterm -- emacs` works fine
<lw>will I have to run that commands everytime I'm opening emacs?
<lw>just `build` it, and works afterword
<lw>How your emacs builds looks like? Do you have a one-liner which install everything you use?
<HiltonChain[m]>I'm using guix home: <>
<lw>What do you mean buy guix "home"?
<johnabs[m]>Hi all, I asked here recently about an issue with building xmonad and ld not being able to find librt due to an update in glibc (I think) and the subsequent gcc-toolchains. Has anyone else managed to find a way to deal with this, per chance?
<pkill9_>im running guix on fedora, and when i run quasselclient from guix it doesn't use a dark theme whereas native fedora one does, i'm wondering what might be causing it not to do so, anyone know why this might be?
<pkill9_>oh, it needs qt5 style plugins i think, which appear not to be packaged in guix
<HiltonChain[m]>lw: Some messages didn't come to Matrix...
<HiltonChain[m]><johnabs[m]> "Hi all, I asked here recently..." <- The packaged xmonad has substitute atm. Do you mean another one?
<lw>HiltonChain[m]: No problem :)
<lw>How can I get the complete guix documentation inside emacs?
<HiltonChain[m]>`C-h i m guix'?
<johnabs[m]><HiltonChain[m]> "The packaged xmonad has substitu..." <- It's possible I'm using the incorrect terminology: I have the xmonad substitute installed; however, I need to run xmonad --recompile to get my configuration working every time an update is installed. For this, it requires both xmonad, (and xmonad-contrib), but also gcc-toolchain to build the new file that is run when xmonad is called. For right now it is "working" but none of my
<johnabs[m]>configuration settings are reproducible, and when I try to rebuild my config, I get the error from ld that -lrt is missing. I hope that clarifies things, and that it makes sense :)
<HiltonChain[m]>librt is from glibc, can you try again with this package in you profile?
<HiltonChain[m]>hmmmm, gcc-toolchain has glibc...
<lilyp>Is there a magic trick in guix graph to cut the graph at a certain point?
<foxfromabyss>hey :) i have managed to install emacs 30.0.50 with tree-sitter on one of my devices with GuixSD. But I can't manage to reproduce the installation on either of the devices for `emacs-next-tree-sitter` and end up getting 29.0.91. Am i missing something?
<lilyp>Yes, a time machine
<lilyp>30.0.50 was tailing the master branch when emacs-next had version 29.0.90
<foxfromabyss>ahhhhhhhhh i see now, that makes sense
<foxfromabyss>thanks a lot
<lilyp>They got unified for 29.0.91
<foxfromabyss>yepyep, gotcha
<lilyp>Note that it ought to have tree-sitter still :)
<foxfromabyss>that's what i am thinking as well!
<lispmacs[work]>does anybody want to push my awesome new package patch I uploaded a few days ago?
<lispmacs[work]>I marked it as severity "normal" but I meant to select "top priority drop everything else you are doing"
<mirai>lispmacs[work]: unless this is some encoding trickery, you have @@url
<mirai>in the description, it should be @uref{…} (or @url{…})
<lispmacs[work]>that is just what the importer spit out
<lilyp>I don't think we need to link to the wikipedia article on HTTP, an @acronym would work
<lilyp>You are free to revise descriptions
<lilyp>license is indeed GPL3 only
<lispmacs[work]>lilyp: is "@acronym" a form of some kind, or you mean just use the acronym
<VesselWave>lw: Have you received my email?
<lilyp>@acronym is IIRC the correct texinfo markup for acronyms
<lilyp>I do confuse it for @abbrev all the time tho, so make sure to watch the log from make :)
<lispmacs[work]>and only one @ symbol instead of two?
<civodul>sneek: later tell attila_lendvai re disabled Shepherd services, could you please email bug-guix stating how to reproduce the problem? i'm happy to take a look afterwards, time permitting!
<mirai>lilyp: @abbr is for things like Mr
<mirai>re serializer-kwargs, is serializer-options really the way to go? It is used as (apply serializer field-name value serializer-kwargs)
<mirai>options seems to imply either some sort of "global state"
<wheref>Is there some special group I need to add to my user in order to use guix without being root after installing it via the install script ( on my foreign linux distro?
<lilyp>at the very least, the kw is misleading
<wheref>I'm getting a remounting permissions error
<lilyp>I personally also prefer actual nouns over abbreviations where possible (args)
<lilyp>perhaps "serializer-details" is a better name?
<civodul>wheref: hi! the script, if you fetched it today, installed the SELinux policy
<civodul>however some issues in that file are fixed in "master" only:
<civodul>what you can do is fetch and apply the relevant part of the diff to your own guix-daemon.cil file
<civodul>(not convenient, i admit)
<civodul>see also
<wheref>civodul: ah-hah thank you. any lead at all is great
<mirai>lilyp: yeah, kw wasn't the best choice here
<mirai>in theory serializer-rest / -rest-args would perhaps be truer though I think it sounds cryptic
<mirai>to a newcomer perhaps, no idea for “seasoned” schemers
<lilyp>see my point regardig abbreviations
<lilyp>those are fine for saving space in a paper or describing mathematical workings, but neither applies to the name of a field
<wheref>civodul: nice thanks! that does it
<lilyp>use a proper word that signals purpose
<lispmacs[work]>okay, patch changes submitted:
<mirai>I wasn't sure if serializer-rest-arguments would have been refused on grounds of length but ok
<mirai>I'll expand that one out
<johnabs[m]><HiltonChain[m]> "librt is from glibc, can you..." <- Right, so what happened was that librt was merged into glibc, and now LD can't find the files (I think, jpoiret and I discussed this a bit) but the problem is that now all gcc-toolchain versions available rely on glibc 2.5 (I think) so even if I install the new version, would gcc-toolchain be able to see that correctly?
<lilyp>mirai: again, the point is not to write out "arguments" but to give it a quick and snappy name that needs no abbreviation
<johnabs[m]>s/new/old version
<lilyp>both "options" and "details" would serve that purpose and are no harder to write than kwargs
<mirai>lilyp: what do you think about -rest-arguments?
<lilyp>hi, scheme implementation sitting on Java, how verbose are you?
<lilyp>how about -last-argument-to-apply?
<lilyp>now that's both verbose *and* cryptic :)
<lilyp>sorry for the snark, I tend to get salty when I feel that folks don't read what I'm writing
<mirai>I was thinking on what other shorter names would best express -rest-arguments but wasn't having much success
<mirai>between details and options I prefer options though
<lilyp>what is even expressed in "rest-arguments", though?
<lilyp>imho, "argument" has no meaning, whereas "option" or "detail" does
<csepp>jlicht: i did a clean rebuild of it with make -B guile, it didn't change anything, trying jpoiret 's suggestion to upgrade everything
<sneek>Welcome back csepp, you have 1 message!
<sneek>csepp, jlicht says: Can you try clearing "./guile" in your guix checkout dir? I may have more cargo cult tips if that does not work :)
<csepp>jpoiret: oh i forgot, i can't upgrade because of that libffi version conflict that i made a bug report about that no one replied to :/
<csepp>fricking great....
<csepp>propagated glib fricking everywhere
<csepp>okay, what the hell, it says i have two different version of eog, but display the same version twice with the conflict being tracked to libffi????!
<csepp>so there are a few things wrong here
<mirai>lilyp: I've finished applying changes based on your feedback, thanks for the speedy review
<mirai>I've also went ahead and patched the jami-service to reflect the newer changes
<lilyp>mail already sent?
<mirai>not yet, running a final "make clean + check" to ensure that things are really properly working
<mirai>clean-go *
<csepp>okay, libffi thing solved, somehow guix upgrade was picking the wrong versions, i figured it out by exporting a manifest, editing out the versions, and installing that manifest
<apteryx>mirai: if the jami tests are good, then it's probably OK :-)
<jpoiret>csepp: nice! do you know if that solved your issue?
<ngz>Hi Guix
<ngz>I only briefly tested new updater behaviour, which is to also update inputs, but for the time being I am under the impression that it somehow gets in the way.
<ngz>But I may have been unlucky about the packages I tried to update.
<mirai>lilyp: sent RFC-v2
<rekado>ngz: you can control the behavior with new package properties
<rekado>the idea is to improve the importers to a point where they only need minor to no hints to do the right thing
<rekado>I used the new updater behavior for my recent mass update of CRAN packages and it worked pretty well
<ngz>There are glitches, tho. For example, it turned (inputs (list bash)) into (inputs (list)).
<rekado>yes, that’s because it cannot remove the whole field.
<rekado>(I had the same issue and asked civodul about it)
<johnabs[m]>Hi all, any ideas on how to make librt accessible to ld for an xmonad recompile process? I just want to make sure my prior questions didn't get lost as I'm completely stuck 😅
<apteryx>mirai: be sure to test the jami-provisioning-partial test
<apteryx>*to run
<apteryx>the jami service does something not too common which is to lower the record objects into the builder and working with these there, including the unset values
<cwebber>got a pinetab2 and didn't realize we were ordering something so *brand new*! I wonder how hard it will be to get guix running on it... I'd definitely love to run Guix on it if I can. I'm not sure if the pine64-image-type works with the quartz64
<cwebber>I guess I'll give it a shot and see what happens
<cwebber>giving it a try now
<davidl_>when is the wip-postfix branch gonna land in master?
<davidl_>or, rather what remains for it to be merged?
<davidl_>reviews? tests?
<mirai>apteryx: ah, I only did tested with "make check"
<mirai>forgot about the system one
<mirai>running one now
<lilyp>mirai: don't forget to update the test for "kwarg-config" accordingly. I'd do one function with an #:optional argument and another with a keyword
<Guest28>if I have an custom channel, how can I test it quickly without committing to it and running guix pull=
<mirai>lilyp: the test happened to be really a keyword test so I didn't change it
<mirai>is there really a need for an #:optional argument test though?
<mirai>the macro doesn't really care what you put within the list, since it ends up being used within an apply
<lilyp>that's the point, though, it shouldn't be limited to keywords only and optional arguments ought to be received faithfully
<lilyp>you could do a mix of optional and keyword arguments too
<mirai>the serializing procedure could take 3 or 99 mandatory arguments and as long the list is of adequate length it will work as well
<lilyp>you probably ought to test those once with a provided and once with a skipped optional now that I think about it
<mirai>won't that be a test on what (apply …) does though?
<lilyp>not sure whether mandatory arguments would be helpful, but you might want to think about the error that occurs when applying an empty list
<lilyp>surely that ought to be a configuration error caught earlier, no?
<mirai>I feel such tests would be whether guile's (apply …) works as intended or not
<lilyp>though for now we can leave mandatory args as UB and do with optionals/keywords
<VesselWave>Guest28: use `-L ~/path/to/channel` to guix install, shell, build etc.
<mirai>an empty list is... valid
<mirai>for apply
<lilyp>I'm not sure whether I can share that sentiment
<lilyp>(apply (lambda (x) x) '())
<cwebber>lilyp: I... don't think I've ever run into this somehow.
<cwebber>and now I'm wondering how
<cwebber>that's very surprising to me
<mirai>I'm thrown off by it as well
<mirai>certainly not what I'd expect from whatever I've read on it
<Guest28>VesselWave thanks, now it says that "no code for module (my-channel packages test)
<mirai>(apply (lambda (x) x) '()) is treating '() as if it were end of arguments?
<mirai>I see it now
<VesselWave>Guest28: You should have a path relative to what you specify in -L. So if your file is ~/dir/dir2/dir3/file.scm and -L is `~/dir/dir2`, you should have (define-module (dir3 file) on top of the file
<mirai>though I don't see why it would be relevant since apply is guaranteed to receive 2 mandatory arguments
<mirai>that is, field-name and value
<mirai>the serializer-options is the last argument to appear within the (apply …) call
<lilyp>(apply (lambda (field val i-really-need-this-value-tho) ...) "hello" "world" '())
<mirai>I guess you could creatively devise serialize-<type> procedures that take one or none arguments if you tweak the transducers
<VesselWave>Guest28: I guess you should just put (packages test), without my-channel
<mirai>that would raise an exception since the serializer doesn't get what it wants
<lilyp>true, but it'd also be a case of bad serializer design as opposed to optionals or keywords is my point
<graywolf>Hi, just reporting that I got duplicite item in RSS feed of Guix blog. It seems entries were updated and now end with // (...for-gnu-guix//) instead of / (...for-gnu-guix/). Not sure if it was intentional.
<lilyp>if you have a serializer with a mandatory third argument, you basically always have to provide that argument with next to no real indicator that you can do wrong at compile time
<mirai>perhaps I'm misunderstanding but what scenario should be covered with a test as well?
<lilyp>Test 1: (lambda (field value #:optional something) ...)
<lilyp>Test 2: (lambda (field value #:key something) ...)
<lilyp>Test 3: (lambda (field value #:optional something #:key some-other-thing) ...)
<lilyp>for instance, section specifiers in ini fields could easily be #:optional
<mirai>What is to be tested here and where will this take place?
<lilyp>whereas quoting styles and other fluff could be #:key (there are different ini formats out there)
<mirai>re INI sure
<lilyp>"What is to be tested here" serializer-options?
<lilyp>"Where will this take place" In exactly the same file that has the kwarg test right now, but using consistent vocabulary
<mirai>Won't the test boil down to whether (apply serializer name value '("foo")) and (apply serializer name value '(#:section "foo")) are working as intended?
<lilyp>isn't that what the current test does in a limited form? :)
<mirai>by limited you mean the presence of #:section?
<Guest28>VesselWave hmm, now it says it can't find the value and I should import the module I already imported
<mirai>it's just a symbol like any other (I think), it could have been @loofus or *:strange-thing:* (provided the serialize-type procedure has the right signature)
<lilyp>by limited I mean that it only checks the keyword case
<Guest28>VesselWave for better overview
<lilyp>I argue that for INI sections #:optional with a default would be a better pattern
<mirai>if a (define-config foo …) were to provide unexpected data like (serializer-options '(#:section "foo" "what is this")) ?
<mirai>looks GIGO to me
<lilyp>are you deliberately missing the point?
<lilyp>Test 1: (lambda (field value #:optional something) ...)
<lilyp>Test 2: (lambda (field value #:key something) ...)
<lilyp>Test 3: (lambda (field value #:optional something #:key some-other-thing) ...)