IRC channel logs


back to list of logs

<rekado_>options->transformation returns a procedure that takes a package as its argument
<rekado_>in the above snippet that returned procedure is immediately applied to nnn
<kabouik>Thank you very much unmatched-paren, I really appreciate the help. Unfortunately I'm not succeeding with this code. First the patch was not found despite correct file names and .scm and .patch being in the same dir, as if ,(search-patch) needed an absolute path, and then when I provided one, I got "guix build: error: invalid Git URL replacement specification"
<gnucode>hello guix!
<gnucode>I am currently playing with setting up a minimal sway session in a wm.
<gnucode>basically wterm does not work on sway, and when I write the bug report, it would be nice to include a vm image to test it.
<pkill9>i cant remember, does guix not output the build of an inferior package being built?
<yewscion>Hey all, is there a list of gexp-usable variables somewhere? I have just discovered #$output as a very useful tool, and I'm currently looking to learn more.
<yewscion>Also, I'm specifically looking for a way to reference the phases of an inherited package's parent, rather than repeat phase definitions in both.
<gnucode>does anyone here have a guix system vm that lets you run sway ?
<gnucode>I am trying to set up such a vm, but I keep getting "cannot get DRM lease" errors when I run the vm. I am currently running sway on guix system.
<kabouik>How does one exit a guix shell?
<yewscion>kabouik: exit should work, so should C-d.
<gnucode>i am starting to wonder if you can run sway inside looks like qemu is running X anyway.
<kabouik>Thanks yewscion. ^D was exiting my actual shell (not guix shell) on the first hit (going from fish to bash), with no guix shell exit hints, so I thought it needed a guix subcommand.
***Xenguy_ is now known as Xenguy
<yewscion>Does anyone know where I can pull stubs-32.h in a 64-bit package build? Seems like overkill to add a cross-glibc to the inputs just for that one header.
<ulfvonbelow>> "guix build: error: invalid Git URL replacement specification" kabouik: the suggested (with-git-url . "") should actually be (with-git-url . "nnn=")
<ulfvonbelow>sneek: later tell civodul: the only places I can find git-checkout mentioned in the manual are in documenting --with-branch in 'package transformations' and source-file-name in 'invoking guix lint'
<atka>sneek: botsnack
<apteryx>"Authenticating commits 9edb3f6 to 525688e (39,006 new commits)..." wait, what?
<apteryx>oh, I deleted ~/.cache earlier
<kabouik>That was something I tried and as far as I remember the issue was still there ulfvonbelow
<kabouik>I started sinking time into another package but will check again
<kabouik>Actually, to my great surprise, this other packages does build and seems to work:
<kabouik>There's one issue though: guix download doesn't give the same hash as the one `guix build -f nmail.scm` obtains. And same if I guix download https://.../3.74.tar.gz. This is obscure to me, since the commit I indicated in the package is the latest, so guix download on the git url should fetch the same commit I believe
<kabouik>So for now, I manually changed the hash based on what guix build -f nmail.scm showed, but that can't be left as is
<kabouik>I posted the wrong nmail.scm, here's the one that works (with hash taken from guix build -f nmail.scm erroring out the first time, not from guix download):
<kabouik>In fact I listed in the nmail.scm the latest commit corresponding to v3.74 release tar ball, so the actual hash from guix build should match that from guix download url-to-tarball3.74
<ulfvonbelow>kabouik: you'll find that 'guix download' will often give you different hashes and contents between different invocations. If you liik at the contents of the store path it spits out, you'll see why (hint: it starts with '<!DOCTYPE html>')
<ulfvonbelow>does the 'guix build' hash agree with that produced by this sequence of commands?
<sneek>atka: Greetings!
<trevdev[m]>Is there any reason I should feel compelled to keep all of my guix related configuration in ~/.config/guix, other than "it's the XDG way?" Could I maybe convert my ~/.dotfiles directory into a guix home setup without fear of breaking something?
<iyzsong>i write a simple home service (dothome) for 'dotfiles' and text formarted packages 'manifest' here:
<wingo>kind guix ppl. i have a laptop running guixsd and gnome. lately when i suspend it, something in gnome-settings-daemon breaks -- e.g. my media hotkeys don't work any more. if i kill gsd-media-keys after resuming, it respawns and things work again. does this ring a bell?
<wingo>same with any other gsd-* daemon afaics, they seem to all be not working after resume
<wingo>i updated it a week ago or so, but the problem has been there for a few months now
<ouroboros86>Is it just my machine or does the current ISO not work?
<ouroboros86>All I get is a grub rescue prompt complaining there is no valid filesystems when I try to boot off a thumb drive.
<unmatched-paren>kabouik: i don't think search-patch searches cwd
<unmatched-paren>you'll need to do -L . for that
<rekado>wingo: I also use Gnome, but I don’t see this problem. I rarely ever reboot; always suspend and resume.
<wingo>i wonder what my deal is
<wingo>also. trying to upgrade a guix-on-ubuntu system i just got:
<wingo>wingo@milano:~$ guix pull
<wingo>Migrating profile generations to '/var/guix/profiles/per-user/wingo'...
<wingo>guix pull: error: symlink: File exists: "/var/guix/profiles/per-user/wingo/current-guix"
<wingo>is a somewhat ancient installation but that's a weird error
<unmatched-paren>i think we've seen this before
<unmatched-paren>i can't remember anything about it, though :(
<rgherdt>unmatched-paren: a while ago you mentioned you would be interested in implementing an LSP client for neovim using scheme-lsp-server. FYI I released a new version of the server yesterday, it should be much easier to create new clients now, since the server works "standalone" and doesn't require a REPL in the LSP client or something like that.
<rgherdt>unfortunately it's not available in guix yet
<iyzsong>wingo: sound like this: i'm not sure if the workaround works though...
<unmatched-paren>rgherdt: I, uh, --was enlightened-- switched to emacs since I said that :P
<rgherdt>:) good move
<rgherdt>you'll never come back, I also did that years ago
<unmatched-paren>There are a few things to dislike in it though
<rgherdt>someone else wrote to me offering help to add support to neovim, I'll contact him again
<unmatched-paren>It's significantly slower than neovim, for one thing
<unmatched-paren>but the lisp support is *so much better* as you might expect :)
<rgherdt>that was the main reason I switched. Then I realised how much I love the interactivity emacs offers, like writing functions on the fly to get the work done etc.
<unmatched-paren>I also don't like how it tries to subsume the desktop environment/window manager
<iyzsong>how to use bitmap fonts for GTK3? when I set 'gtk-font-name' to 'terminus 10', it's like 'sans 10'...
<unmatched-paren>I still use external applications, I only use emacs for the editor
<unmatched-paren>(and magit)
<unmatched-paren>e.g. I've set aerc's editor to emacsclient instead of using mu4e, gnus, or something
<iyzsong>um, seem i have to find some OTB (opentype bitmap) fonts for GTK/pango.
<rgherdt>I only started appreciating other stuff of emacs after starting coding elisp. Comparing writing extensions for emacs and vscodium is like night and day
<unmatched-paren>Well, I think neovim's lua support makes it just as nice to extend
<unmatched-paren>especially since fennel exists
<rgherdt>at least that's the lesson I took from this experience writing both LSP clients
<rgherdt>but do you have the same experience like jumping to any definition, changing any function on the fly, getting access to internal variables/functions etc?
<rgherdt>or is lua restricted to some extension API?
<rgherdt>like, in emacs you type Ctr+. on the symbol 'move-beginning-of-line' and you see it's definition
<rgherdt>you can even change it
<unmatched-paren>no, it's nothing like that i guess :)
***wielaard is now known as mjw
<rgherdt>I meant Alt+. :P
<unmatched-paren>Is it possible to use gexp with snippets?
<unmatched-paren>(snippet #~(begin ...))?
<wingo>iyzsong: thanks!
<nckx>unmatched-paren: Yes.
<unmatched-paren>nckx: Thanks
<iska>how do I get X in containers?
<unmatched-paren>why isn't this working as the snippet? let ((tar (string-append #+tar "/bin/tar")))
<unmatched-paren> (invoke tar "xf" #+notmuch-fixtures "-C" "fixtures")
<unmatched-paren> (substitute* (find-files "\\.go$")
<unmatched-paren> (("-lnotmuch" flag)
<unmatched-paren>i meant to post a link
<unmatched-paren>let ((tar (string-append #+tar "/bin/tar")))
<unmatched-paren> (invoke tar "xf" #+notmuch-fixtures "-C" "fixtures")
<unmatched-paren> (substitute* (find-files "\\.go$")
<unmatched-paren> (("-lnotmuch" flag)
<unmatched-paren>for some reason guile is saying that `tar` is an unbound variable
<unmatched-paren>even though (gnu packages base) is imported
*civodul just reviewed & pushed 42 patches \o/
<bruun>Anyone able to tell me how to run halt/reboot without root privileges? Main motivation is convenience, i.e. run the commands via swaynag, which is unable to prompt for a root password (at least to my knowledge)
<iyzsong[m]>civodul: crazy productivity! i always wonder how you can do so and when i will too ❤️
<dirtcastle>what does guix install no substitutes options do? the manual says it builds packages from source? does it mean compiling? if it's bejng compiled from source,the source code in text files should be very small in size. but I saw 20mb tarballs being downloaded.
<iyzsong[m]>bruun: you can setup sudo without password
<iyzsong[m]>dirtcastle: depend on the target package, source can be huge as GB
<civodul>iyzsong[m]: i cheated a bit: there were two long patch series that were easily reviewed :-)
<civodul>iyzsong[m]: BTW, i was glad to see you back on the hack and reviewing things!
<iyzsong[m]>yeah :)
<dirtcastle>they are just text files with code in it right? how can they be so big?
<civodul>dirtcastle: yes, passing --no-substitutes leads Guix to compile things on your machine; to do that, it'll first download source code, which can sometimes be big
<civodul>that's just text files, but a whole lot of them :-)
<civodul>usually the resulting binaries are orders of magnitude smaller than the initial text files
<muradm>civodul: 56971 :)
<civodul>muradm: hi! :-)
<civodul>i spent the morning reviewing patches, i can't work any faster, sorry!
<muradm>no issue :) just pinging :)
<muradm>looking at url-fetch, wandering why not simplify by using guile-curl for instance?
<rekado>is it really simpler to use a third-party library and its bindings instead of just using Guile?
<antipode>muradm: guile-curl does not appear to be integrated with guile-fibers, which makes using fiber-based libraries in (guix download) and friends harder
<antipode>(I intend to add support for downloading gnunet:// things to url-fetch using the (Fibers-based) GNUnet-Scheme library)
<vivien>In my own opinion, it is OK to spawn a full thread to do a request, because you wouldn’t do millions of requests per seconds anyway (unless you are an attacker)
<antipode>Performance-wise, I agree it should be acceptable, but it seems somewhat inconvenient to me.
<kabouik>Thanks ulfvonbelow. I am not at home right now and still haven't solved my SSH issues from WAN (I can ping the device but not ssh into it), but I don't remember seeing the hash showing in your paste
<kabouik>Will check later when I'm home.
<kabouik>Speaking of, my current daily machine is not running Guix OS but Solus. I'd like to install just the Guix package manager to experiment (I don't have enough free space for a full Guix VM). Is there a way I can restrict it to a given drive and folder? Last time I tried it, I remember there was files not only in /gnu/store but also in other folders for configs, and that made me uneasy.
<kabouik>Plus here the disk I use for / is full, so I'd need to give it another drive if possible.
<drakonis>that can be done, yes.
<drakonis>you can spin up a guix vm with just the package manager
<drakonis>guix system vm /path/to/configuration
<drakonis>its how i tested your config out last time
<kabouik>But I don't have guix (package manager) installed yet on this machine, I would want it to be on a certain drive/folder too. I don't think that would be straightforward to do.
***civodul` is now known as civodul
<drakonis>relocating the store? i dont know about that one
<kabouik>That would be my first issue because I only have 3GB free on the ssd, and that already causes enough issue without Guix at all :p
<kabouik>Might be more reasonable to just wait until I'm home and can play with the machine running Guix system.
<drakonis>store relocation hasnt been worked out that well?
<kabouik>I'll try the QEMU vm, see if my other drive has enough free space for it
<kabouik>It shouldn't be all that big (900MB compressed) for my other drive
<iyzsong[m]>kabouik: they are /gnu, /var/guix and /etc/guix, you can create an filesystem and mount it on /gnu, and in it create var and etc, then link later 2 to their dirs in /
<drakonis>that is a way too
<drakonis>bind mounts can do that
<drakonis>though i don't think the installer lets you pick which filesystem you're going to place the directories
<drakonis>oh wait
<drakonis>you can!
<kabouik>That's encouraging but if it's not planned in the installer, that may be another rabbit hole to deep for my skills
<kabouik>So I'll try with qemu and see after if I need something else instead
<drakonis>kabouik: you most certainly can
<drakonis>you have to pass an environment variable for that
<iyzsong[m]>by use mount and symlink, you can store data on the desired filesystem, no location changes required.
<drakonis>but how do you get them on the other filesystem first?
<drakonis>do you relocate them after the install?
<drakonis>also the first install doesn't take up a lot of storage space, so it is a viable thing to do and think about
<pkill9>iv'e forgotten, how do you download a store patha nd it's dependencies from a remote machine without setting up any services?
<pkill9>i know you need to authorize a machine's key
<pkill9>but can't remember the command to download the store paths
<iyzsong[m]>it's just some directories, mv will do.
***zgcarvalho40 is now known as zgcarvalho
<pkill9>ah guix copy
<pkill9>how do you copy store paths recursively?
<iyzsong[m]>in /, /gnu is an empty dir in fs for /, and /var/guix is a symlink (mount will do too) to another directory in your desired fs.
<kabouik>The qemu image is actually alrady in qcow2, so no need to extract it, and it is less than 1GB
<kabouik>So that should work
<iyzsong[m]>if you are migrate /gnu, just mv /gnu/store into another fs then mount back.
<pkill9>ah nice, it copies them recursively
<kabouik>There might be a mistake in that how-to by the way: It says that the image is in qcow format and needs to be extracted, but it comes in qcow2 and runs just fine un qemu right away.
<iyzsong[m]>um, i think it was xxx.qcow.xz.
***Xenguy_ is now known as Xenguy
<davidl>unmatched-paren: yes re: paste thing. I forgot, sry.
<civodul>uh, links to the manual from are wrong now (extra "/guix" and missing "/devel")
<muradm>antipode: i see thanks..
<kabouik>ulfvonbelow the trick was probably to clone the repository and exclude the versionning subfolder indeed, which you did with guix hash but I thought guix download would work directly after what I read in the manuals
<kabouik>So should work (works for me in a fresh Guix VM), if anyone else wants to check. If it ok, then I guess I could try submitting it for Guix channel, since I think nmail would be a cool addition.
<kabouik>Wrong url:
<kabouik>Thank you for solving my hash issue ulfvonbelow.
<drakonis>civodul: why isn't the devel manual the "default" one?
<drakonis>shouldn't there be a stable link instead of a devel?
<drakonis>i've run into issues with helping people that were looking at the stable manual instead of the latest one
<pkill9>guix needs a tools like aptitude
<pkill9>well, output like aptitude
<pkill9>so you can see the build output in one frame and the other frame shows the overall progress
<pkill9>in an ncurses interface
<ulfvonbelow>kabouik: you're welcome, and regarding, whenever we put #:tests? #f it's courteous to include the reason (e.g. no tests included, tests require network access, tests require complex circular dependencies, etc), so that we can tell whether to try enabling them in future versions.
<ulfvonbelow>also, I've noticed that 'guix package -u ...' leaves all output to my emacs shell buffer bolded and I can't figure out how to reset it from the emacs side
<kabouik>The honest answer to that ulfvonbelow is #:tests? #f was failing with errors I don't remember so I wanted to see if I could go further with no tests, and realized it just compiled and launched as it should (which I didn't expect). In the joy of that moment after one week struggling with the most basic things in Guix, I kinda forgot I disabled tests in the first place.
<kabouik>I'll have to check again why they were failing.
<ulfvonbelow>makes sense
<kabouik>I think there should be tests since the nmail devs provides a script that takes a `test` subcommand. Looking at the script, test just seems to run `ctest --output-on-failure`
<apteryx>wingo: I think it was a bug that got fixed. You'll need to workaround to get passed it, but it shouldn't come back at a later point in time
<podiki[m]>apteryx: what is the latest on the qt wrapping bug, is that supposed to be fixed in general? noticed yesterday vorta fails on qt wrap (it is python build and then pulls that phase from qt build system)
<nckx>drakonis: It's been discussed to death already that devel should be default. Berlin is not currently in a state that makes me comfortable enough to apply that patch, though.
<drakonis>ah, okay
<nckx>First we fix the boot loader, then we fix the links, then we feast.
<nckx>I might have omitted a good few steps there.
<apteryx>podiki[m]: hi! the mass failures for Qt 5 due to the #:qtbase arg were fixed; there's still some possibility of regression because of the use of new style inputs. See aea756ea3312ba7e8229804492ba12001c8de568 for an example of a fix.
<podiki[m]>hmm. vorta just pulls the qt wrap phase from qt-build-system to add to it's python build
<podiki[m]>so I'm not sure what is going on there
<podiki[m]>I guess it needs the qtbase arg added somehow
*apteryx tries
<apteryx>podiki[m]: your analysis seems right
<podiki[m]>how does one add in an arg from a different build system?
<podiki[m]>I already tried adding a qtbase input, but that didn't seem to work
<apteryx>I think we'll have to hack it at the level of the phase call
<apteryx>yeah, it doesn't use it from inputs (in theory there could be qtbase 5 and qtbase 6 there, this was the rationale for making it explicit via #:qtbase)
<apteryx>I guess an alternative would be to have qt-major-version, the nested variable of wrap-all-qt-programs, fall-back to "5"
<apteryx>when qtbase is #f
<podiki[m]>is this something we see anywhere else? I didn't search, but looks like would be for anything that doesn't use qt-build-system but wants to wrap automatically rather than manually writing a phase?
<apteryx>It'd affect anything that borrows the qt-wrap phase from qt-build-system, which is *not* using the qt-build-system
<apteryx>this fixes it:
<podiki[m]>ah, I see others do it but with explicit "wrap-qt-program" call
<podiki[m]>e.g. qtpass which does build currently
*apteryx greps for "assoc-ref qt:%standard-phases 'qt-wrap"
<podiki[m]>my grep of "wrap-qt-program" only turned up vorta grabbing it as a phse
<podiki[m]>jinx :-)
<podiki[m]>ah, a few others with your search
<apteryx>bitmask and qt5ct
*apteryx tests fixes on them
<podiki[m]>e.g. hime
<podiki[m]>yes, same failure
<podiki[m]>I thought "nimf" was from being jinxed
<podiki[m]>ah, this was noted in an update to a patch:
<podiki[m]>odd, did not get that email in my inbox despite being the original submitter
<unmatched-paren> "Go has a culture of rejecting large dependency trees, and of preferring a bit of copying to adding a new dependency." <- Has whoever wrote this blog post ever SEEN a Go package?!
<unmatched-paren>I still haven't figured out why `(snippet #~(let ((tar-bin (string-append #+tar "/bin/tar"))) ...)) doesn't work :(
<civodul>unmatched-paren: doesn't work as in "no code for module", right?
<unmatched-paren>"error: tar: unbound variable"
<unmatched-paren>(gnu packages base) *is* imported
<unmatched-paren>into the outer environment, I mean
<apteryx>unmatched-paren: probably some module import dependency loop
<unmatched-paren>i'll try using the module-ref/resolve-interface thing
<apteryx>there was some talk of making snippet a delayed field in the past to work around this
<apteryx>unmatched-paren: perhaps they meant vendoring the world as 'a bit of copying'
<unmatched-paren>Oh, hmm.
<unmatched-paren>#+(module-ref (resolve-interface '(gnu packages base)) 'tar)
<unmatched-paren>No variable named tar in #<interface (gnu packages base) 7f8d93782d20>
<unmatched-paren>But `guix edit tar` drops me into base.scm.
<apteryx>podiki[m]: I pushed a956c7df87 to fix bitmask, hime, hime, nimf and vorta
<podiki[m]>great, thanks!
<gnucode>hello guix!
<unmatched-paren>hi gnucode
<gnucode>what up unmatched-paren ? Yo! made this awesome dubbugs function. One second.
<unmatched-paren>hmm, apparently patch-inputs suffers from the module import loop problem too
<unmatched-paren>but i still don't understand why even module-ref didn't work
<civodul>unmatched-paren: yeah, variable references in 'snippet' are resolved from the top level (i.e., when loading the module)
<gnucode>What do you think of that? unmatched-paren ?
<civodul>thus they break in the presence of circular module dependencies
<unmatched-paren>Eh, I can just use a phase to open the tarball anyway.
<gnucode>It queries debbugs to show you all of the open bugs that you have personally have submitted.
<unmatched-paren>gnucode: useful!
<gnucode>And it will work for you as is! Assuming that you have defined user-mail-address in your .emacs.d
<unmatched-paren>Although you seem to have a redundant usage of `eval`, at least to my scheme-trained brain
<unmatched-paren>gnucode: And assuming that emacs-debbugs is installed :)
<gnucode>yes. :)
<gnucode>unmatched-paren what do you mean by redundant?
<unmatched-paren>gnucode: You could use (apply #'debbugs-gnu-bugs my-bug-list) I believe
<unmatched-paren>instead of that eval
<gnucode>my-bug-list is a list. I have to pass that list into the function like so (debbugs-gnu-bugs number1 number2 number2 etc)
<gnucode>ahh! THanks for that!
<gnucode>may you remind me what apply is better than eval here?
<unmatched-paren>Well, I'm pretty sure eval is literally the interpreter
<unmatched-paren>so you're running an entire interpreter function just for that :)
<unmatched-paren>but apply just applies the function, and that is all
<unmatched-paren>(applies it to a list, I mean)
<unmatched-paren>and it looks cleaner IMO anyway :)
<unmatched-paren>gnucode: Also, why are you doing:
<unmatched-paren>(let (my-bug-list) (setq my-bug-list VALUE) ...)
<unmatched-paren>instead of
<gnucode>unmatched-paren: gotcha. :) Thanks for the improvement tip. Also, I think it would be an awesome addition to guix. We could put it in the guix-development package
<unmatched-paren>(let (my-bug-list VALUE) ...)?
<unmatched-paren>gnucode: Why not submit it to emacs-debbugs directly?
<gnucode>unmatched-paren that's another good tip!
<unmatched-paren>In fact, I think you could just do
<unmatched-paren>(apply #'debbugs-gnu-bugs (debbugs-get-bugs :submitter "me" :status "open"))
<unmatched-paren>no intermediate variable is really needed
<gnucode>yup! I just changed it! Thanks! you're a genius!
<unmatched-paren>not really :)
<unmatched-paren>Nothing of the sort. Most peopl here are orders of magnitude smarter than me.
<unmatched-paren>s/peopl/people/ :)
<unmatched-paren>For the apply thing, I knew there was such a form in guile, so I looked up 'emacs apply function to list' and found that elisp also had apply
<unmatched-paren>and for let, well, binding local variables kind of is what it's for...
<gnucode>unmatched-paren: What do you think about adding that function to the $guix-src/etc/debbugs-helper-functions.el ? Then in the manual, we could tell people, from time to time your old bug reports get forgotten. The guix community invistes you to periodically invoke M-x my-open-bugs and try to close your old bug reports. What do you think ?
<unmatched-paren>Nice idea
<gnucode>I am happy to quickly submit a patch! as well as documentation. If you say so, I'll start working on it now.
***Guest1076 is now known as Guest95
<unmatched-paren>Yay, I made it work without propagating notmuch :)
<unmatched-paren>Now to send aerc patchset, uh, v6...
<unmatched-paren>One day this patchset will be merged! ONE DAY!!! :)
***Dynom_ is now known as Guest8760
<unmatched-paren>Could somebody take a look at It's only one really tiny package :)
<antipode>unmatched-paren: on tar: because cycles.
<antipode>You'll need to delay evaluation somehow.
<antipode>Maybe delay evaluation with 'with-parameters'.
<antipode>Try: (snippet #~(let ((tar-bin #+(file-append (with-parameters () tar) "/bin/tar"))) [...]))
<antipode>(the string-append -> file-append change here is not strictly required)
<antipode>civodul: for these kind of cycles, maybe we can have a '(delay-object [...])'? with (delay-object [...]) equivalent to (with-parameters () [...])?
<unmatched-paren>antipode: Thanks, noted, but I realized it was possible to do what I wanted in a phase :)
<unmatched-paren>The Cgo patching, though, had to be done in a snippet.
<unmatched-paren>Because then the source output itself is modified, and the change propagates to any dependent Go packages.
***mark_ is now known as mjw
<kabouik>Re: #:tests? #f ulfvonbelow: does "make: *** No rule to make target 'test'. Stop." ring a bell? This is what I get when I enable them.
<kabouik>And "%exception #<&invoke-error program: "make" arguments: ("test" "-j" "4") exit-status: 2 term-signal: #f stop-signal: #f>"
<unmatched-paren>kabouik: Maybe try #:test-target "check"?
<unmatched-paren>Though I don't understand why it'd try "test"; I thought "check" was the default.
<kabouik>Trying, thanks unknown
<kabouik>unmatched-paren (sorry)
<unmatched-paren>No problem :)
<kabouik>Nope, no rule for "check" either
<unmatched-paren>What package is this? Could you link to the source?
<kabouik>I guess that would justify a "#:tests? #f ;;No tests included with sources"?
<unmatched-paren>I suppose so, but they might be under some strange target name
<kabouik> unmatched-paren
<unmatched-paren>Ah, yes, that
<unmatched-paren>Home-page link 404s :)
<unmatched-paren>It's d99kris, not d99ris, that's the problem :)
<kabouik>Right, just found the typo too, good catch
<kabouik>Is that what breaks the tests?
<unmatched-paren>Ahh, it's cmake. that's why it tries test
<unmatched-paren>home-page is purely user-facing information
<unmatched-paren>Doesn't seem to include tests.
<unmatched-paren>Do the tests? #f thing :)
<kabouik>The sources include a with a `test` subcommand, but this essentially runs `ctest --output-on-failure`
<unmatched-paren>Although you should change the comment to `;no tests included`
<unmatched-paren>kabouik: Ahhh
<kabouik>Maybe I can try `#:test-target "ctest"`?
<unmatched-paren>You'll want to replace the test phase then
<unmatched-paren>no, that won't work
<unmatched-paren>that'd try to run `make ctest`
<unmatched-paren>Oh, btw
<unmatched-paren>You use some deprecated syntax in that packae
<unmatched-paren>Btw, why do you include `file` as an input?
<kabouik>I probably misinterpreted an error, and doing so made it go away; but perhaps that's not the correct solution
<kabouik>The package needs libmagic which I think comes with file
<kabouik>Is ("libmagic" ,file "lib) better?
<kabouik>Plus the double quote I forgot
<kabouik>("libmagic" ,file) in fact
<kabouik>This seems to compile fine with that (so far; it's not over yet)
<unmatched-paren>kabouik: Ahh
<unmatched-paren>That makes sense
<unmatched-paren>Read the comments beginning with NOTE:, then --destroy-- remove them :)
<kabouik>Do you have anything to recommend in the manual on how to change the test phase? It's not very detailed for cmake
<kabouik>Oh thanks, checking that
<unmatched-paren>If you want to submit this package, you should probably be using a release tag instead of an arbitrary commit
<unmatched-paren>(3.74 i guess)
<kabouik>I see you've altered the synopsis by the way (I was not comfortable with the Linux/macOS mention either, but it's from the developer's git repo; are we free to change that as packagers or is the usual policy to keep it as is?)
<unmatched-paren>We generally change it
<unmatched-paren>Almost all the time, in fact :)
<unmatched-paren>Usually we just write our own synopsises/descriptions
<gnucode>unmatched-paren what does your newest patch do?
<unmatched-paren>Btw, try running `guix lint -L . nmail` to find style problems in the package
<unmatched-paren>gnucode: ?
<unmatched-paren>Which patch?
<unmatched-paren>It adds the aerc email client
<gnucode>oh sick! that's awesome!
<unmatched-paren>(patchset version 6 :))
<unmatched-paren>v6 modifies go-notmuch to directly refer to the and notmuch.h files, instead of simply propagating notmuch
<unmatched-paren>and also fixes its tests
<unmatched-paren>gnucode: Sadly, it's a Go package, which explains the ridiculous number of patches :)
<unmatched-paren>"01/41" *sigh*
<unmatched-paren>If this was a C package, that'd be 1/3 *at most*.
<kabouik>Thanks for the tips unmatched-paren; finishing the pizza and I'll play with them and finish reading your comments!
<gnucode>unmatched-paren I didn't realize that go is hard to package in guix....
<unmatched-paren>gnucode: Not hard per se
<unmatched-paren>Just *incredibly* tedious
<kabouik>Oh so that mean if I can time my package submission correctly, Guix could be getting two new terminal email clients at the same time OO
<unmatched-paren>Also, there is sometimes pregenerated files and vendoring, but that could happen in any package tbh.
<gnucode>what's the best non-C language that is easy to package in guix? emacs lisp. :)
<unmatched-paren>kabouik: Heh. Expect a bit of a wait; the intersection of the sets "people with commit permissions" and "people who thanklessly traverse the patch list, reviewing each one" is quite small :)
<kabouik>No problem, I'll be happy if the package even makes it one day! But would be cool to have moar choices for terminal email clients, they're just so much more effective.
<unmatched-paren>kabouik: It'll take a wee bit longer than a day.
<kabouik>I meant one day, not in one day
<unmatched-paren>Ah, right. Misread :)
<gnucode>unmatched-paren I should probably make a coding video showing people how hard/easy it is to "traverse the patch list" and review patches.
<gnucode>Just having people comment on a patch (this patch work on my machine) would be really helpful to guix.
<unmatched-paren>gnucode: It's more often code style, good conventions, etc that need reviewing
<unmatched-paren>Things like whether it passes guix lint, whether it works with cross compilation, etc
<unmatched-paren>Because if it works on the author's machine, it probably works on most people's machines.
<unmatched-paren>gnucode: I'd think there would be some amount of dependency proliferation for elisp, too
<unmatched-paren>since it also has a package manager
<unmatched-paren>(multiple package managers, actually...)
<unmatched-paren>Pretty much anything with a package manager is annoying to package
<unmatched-paren>I guess Guile may sort of avoid that, it doesn't seem to use too many dependencies usually
<gnucode>unmatched-paren: my only issue with guile is that...well it seems hard to write modern (wayland ready) applications in guile.
<gnucode>case in point: guix has no GUI front-end (yet).
<unmatched-paren>Haskell, Rust, Go, OCaml, Common Lisp, Perl, Python, Erlang, Elm, Javascript, Clojure, D, Java, R, Raku, and Ruby all suffer from the dependency problem, and guess what they have in common? :)
<kabouik>(I wouldn't use a GUI front-end for it, but I could like an optional fzf mode for guix search)
<unmatched-paren>gnucode: GTK+ supports wayland though?
<unmatched-paren>And there's guile-gnome.
<unmatched-paren>I don't think many people would write a Wayland application with their bare hands.
<unmatched-paren>Except for desktop-utility things like mako or swaybar.
<acrow>Glad to be back with guix.
<gnucode>unmatched-paren what programs use guile-gnome? And if you write an application in guile-gnome, will it only work on gnome?
<gnucode>unmatched-paren: I'm guessing all of those languages all have lots of dependencies.
<unmatched-paren>My two guile complaints would be: (1) it doesn't have a type system :( (2) it's sorta functional, but it doesn't want to go all the way
<unmatched-paren>gnucode: The thing they have in common is, what a surprise, a language-specific package manager that makes it trivial to grow your dependency try to massive sizes without noticing!
<gnucode>unmatched-paren I would love to add a type system to guix! That would be awesome!
<unmatched-paren>gnucode: guile-gnome is just a bunch of bindings to GNOME libraries
<unmatched-paren>gnucode: I think a type system has to be designed into a language from the start, tbh.
<unmatched-paren>From a distance, for example, Python's bolted-on type system doesn't look that great.
<gnucode>unmatched-paren ahhh. So everything has massive amounts of dependencies. You will like hare then! They specifically have no official package manager and refuse to add it.
<unmatched-paren>gnucode: I do like Hare :)
<gnucode>unmatched-paren you could create a #lang hardened-guile
<unmatched-paren>We need a hare-build-system for it to be nice in guix
<gnucode>after we get a #lang guile-steel :)
<unmatched-paren>gnucode: I believe you may be conflating Guile with Racket :)
<gnucode>unmatched-paren probably true. :) have you been using aerc then?
<unmatched-paren>Although it's an older version in guixrus
<gnucode>unmatched-paren is it nicer than Emacs ?
<unmatched-paren>Once my patches are merged, I'll be able to remove it from guixrus
<unmatched-paren>gnucode: Well, you can use it with emacs
<gnucode>at reading and applying patches ?
<unmatched-paren>(And I do :))
<gnucode>what!? I did not know that.
<unmatched-paren>gnucode: You can just bind a key to :pipe -mb git am -3
<unmatched-paren>and then you have a key for applying patches :)
<unmatched-paren>gnucode: I just set the editor to `emacsclient`
<unmatched-paren>Though it uses vim keys, so it won't appeal to people who actually *like* the cursed emacs keys.
<gnucode>hmmm. I've been diving into debbugs. And you can apply patches via that inside emacs. I've only done it once, but it was pretty cool. :)
<kabouik>unmatched-paren, you removed the package name on the last line, but now I'm getting errors when calling guix build -f nmail.scm because of that, the error is pretty specific with a clear solution (for once :P)
<unmatched-paren>kabouik: You can use -L .
<unmatched-paren>assuming that the module and the filesystem match up
<kabouik>But then that means guix build -f is pretty much deprecated?
<acrow>vagrantc: full re-write is in progress.
<vagrantc>acrow: oh my!
<vagrantc>acrow: hope you're enjoying this all :)
<unmatched-paren>kabouik: Not really
<unmatched-paren>-f is more useful for one-off project packages
<unmatched-paren>but for writing packages for third-party programs/libraries, you're better to use -L
<kabouik>Hum, but my private-channel is currently locally full of unfinished package projects, each of them more broken than the other, so -L . is unhappy
<unmatched-paren>Okay, use -f if you need to :)
<kabouik>That implies adding the package name at the end. Does that pass the standards for package inclusion?
<unmatched-paren>Use that while iterating on it
<unmatched-paren>We don't include the name in the actual Guix channel
<kabouik>Okay. Thanks.
<unmatched-paren>That name is just you returning the package object at the end of the file
<kabouik>Trying to figure out the hash mismatch between the release commit and the one I get on the .tar.gz; maybe I need to extract the tarball first
<unmatched-paren>-f just evaluates the file and builds the package object that's returned
<unmatched-paren>kabouik: Well, if you've switched to a different commit, or to using git sources, you'll get a different hash
<unmatched-paren>you can hash git sources with
<kabouik>I altered both the commit and the hash
<unmatched-paren>git clone REPO repo-dir && cd repo && guix hash -rx .
<kabouik>Got the commit corresponding to the release, downloaded the tar.gz and ran guix hash on it, but that doesn't match what guix actually finds when trying to build from the .scm file
<unmatched-paren>I think the tarball and the checkout differing is expected
<unmatched-paren>Argh, I just saw some replies on a really long thread of packages and thought it was aerc for a moment :)
<kabouik>Ha. What's the correct way to determine the hash of a release then? Git clone, then revert to the said commit? I mean I know how to check the hash of the latest commit (I was just missing -rx when I tried yesterday, because I was trying to get the hash from guix download which doesn't have these options)
<kabouik>But from a tarball, still puzzled
<kabouik>I'll try just checking out the commit of the release instead of the tarball
<unmatched-paren>kabouik: Yeah, we don't have a git-download command yet
<kabouik>Right, so guix download sends correct hashes for files only, else on git it'll download an html page I assume
<unmatched-paren>Something along those lines, yeah.
<kabouik>(That's a bit confusing, since the manual does recommend guix download and just says that guix hash does kind of the same, as far as I remember, so I was not looking in that direction when I found hash mismatches)
<unmatched-paren>`guix hash` hashes a directory
<unmatched-paren>Sorry, a file. `-r` makes it hash a directory
<unmatched-paren>and `-x` makes it ignore things like `.git1
<unmatched-paren>`guix download` basically does the equivalent of `url-fetch` and hashes that
<unmatched-paren>which is why it doesn't work with git
<kabouik>Yeah, but when discovering both commands and seeing their help, I just thought guix download was the same as guix hash, only guix hash allowed checking files or dirs already present (or which may have no url)
<kabouik>But now I understand the difference indeed
<kabouik>s/already present/already present on disk
<gnucode>does anyone have a snippet of emacs code that lets you search for open bugs in "guix" and "guix-patches" ?
<antipode>gnucode: (on: what's the best non-C language that is easy to package in Guix): Lua, when used in a Minetest mod, is pretty straightforward to package
<unmatched-paren>antipode: Yeah, Lua also seems pretty sane outside of Minetest
<antipode>unmatched-paren: I believe there was a patch or at least a proposal for extending "guix download" to cover git repositories, though it hasn't gone anywhere yet.
<antipode>unmatched-paren: Each "lua-" package seems to have its own #:builder or phases
<antipode>Though to me it looks like it can mostly be solved with a lua-build-system.
<kabouik>The hash hell is not giving me any rest. If I `git clone REPO && cd REPO && git checkout hash-indicated-in-my-scm-file`, then `guix hash . -rx`, the hash still doesn't match what the .scm file is getting when downloading the sources at that commit
<unmatched-paren>kabouik: Could you show the latest version of the package?
<kabouik>Could (file-name …) alter the hash the .scm file is calculating?
<kabouik>a03a09 is the hash of the release 3.74
<unmatched-paren>Why not just use 3.74?
<kabouik>And 1df16 is the hash guix hash . -rx gives me after checking out this commit in my /tmp/nmail
<unmatched-paren>(commit ...) accepts tag names.
<unmatched-paren>Usually we either do
<unmatched-paren>(commit version)
<unmatched-paren>or (commit (string-append "v" version))
<unmatched-paren>depending on how the tag is named
<unmatched-paren>and (version "some-version")
<kabouik>That might work but I admit I'd rather understand why hash don't match in what seemed to be correct Scheme
<kabouik>Also it made it easier to get a specific commit in case of a very important change not yet in a release
<unmatched-paren>I get a completely different hash
<kabouik>That's the one I want. Can you show me how you got it?
<unmatched-paren>after `git checkout v3.74 && guix hash -rx .`
<unmatched-paren>and you can just use (version "3.74") and (commit (string-append "v" version)) here :)
<kabouik>I think I know what was wrong, and of course it was human error (no surprise really, but it's still good to know what it was)
<kabouik>There was a remnant build/ inside my ~/tmp/nmail
<kabouik>Which only gets created when calling the script to install from sources
<unmatched-paren>Hmm, that's disturbing
<unmatched-paren>It shouldn't be leaving directories lying around
<unmatched-paren>(The build, not guix.)
<kabouik>I clone the dir yesterday and probably experimented with the non-guix procedure to install it and see what was doing
<kabouik>Now I checkout to the release commit and it didn't error out, I simply forgot about the build/ directory
<lilyp>antipode: obvious c++ :)
<unmatched-paren>kabouik: Ahh
<kabouik>Now I can get the correct hash with git checkout commit
<kabouik>Well I'll double check with a guix build again but that should be it
<unmatched-paren>And you can remove the (let ...) and git-version :)
<kabouik>Can I leave it too? Again if a commit comes at some point and fix an important issue, I'd prefer being able to use the same package.scm instead of waiting for a release, and still get the detailed version number with commit
<kabouik>Or is that malpractice?
<unmatched-paren>We just use the releases, if there is one
<unmatched-paren>We can backport the patch if really necessary
<unmatched-paren>But I doubt we'll need to do that
<yuu[m]>so shadowbans
<yuu[m]>i'll ask here then
<yuu[m]>how to see the guile source definition of a given symbol?
<yuu[m]>(how to do that in geiser as well?)
<kabouik>It's young and actively developed, for instance one of the bugfixes around the corner will fix directory names for Greek characters, which currently are completely broken (I'm not greek, just read the issue), and I doubt it'll make a new release immediately because the dev usually bumdles more changes in each release
<kabouik>So for me it's not critical, but for Greek people, the future commits may be important ones
<unmatched-paren>how do you break greek characters, they're just well-behaved unicode chars that don't even render large or go RTL
<unmatched-paren>Ah, it's all non-Latin1 chars that are brokn
<unmatched-paren>that would make more sense :)
<antipode>yuu: Symbols do not have definitions.
<antipode>Symbols are just read-only non-changing unique strings except wrapped in its own type.
<yuu[m]>antipode: ofc. i mean their value
<antipode>However, variables (including variables containing procedures) do.
<unmatched-paren>Ohh, it's UTF-7 which is apparently cursed so I don't blame them
<kabouik>Yes I read it's utf-7
<antipode>If it's a Guix package, you can do "guix edit hello" to find the definition of the "hello" package.
<kabouik>And it probably simply wasn't planned in advance, with a small user base it took time until some Greek user reported the issue
<unmatched-paren>Again, though, it's probably not going to bother anyone enough to break from regular releases, and if it does bother someone, we can backport the fix
<antipode>There's some procedure for finding the location where it was defined but I cannot find it.
<antipode>I don't know Geiser.
<unmatched-paren>antipode: For packages, you can do
<unmatched-paren>((compose location-file package-location) pkg)
<unmatched-paren>replacing location-file with location-column or location-line as necessary
<antipode>To be clear, I meant finding the location of procedures and maybe arbitrary variables
<antipode>source-properties !
<antipode>(source-properties map) doesn't seem to work, maybe it's only for syntax ...
<yuu[m]><antipode> "If it's a Guix package, you..." <- antipode: is that guix on the gnu module? i switched to the gnu module but guix edit hello or (guix edit hello) didn't work
<antipode>No. It's the guix command.
<antipode>To be run in a terminal or such.
<yuu[m]>oh ok
<atka>sneek: botsnack
<orneb>Are these errors normal during the boot process?
<unmatched-paren>I've seen "[ 24.481911] udevd[177]: no sender credentials received, message ignored
<unmatched-paren>the pcspkr one, and the Free firmware one
<unmatched-paren>i haven't seen the rest
<unmatched-paren>probably harmless...
<kabouik>Phew, after some brain freezes, garbling the whole file to try implementing your advice on using just tag version instead of commit, I finally reconnected my neurons:
<kabouik>Now I'll check how submissions are done.
<gnucode>-*- var: value -*-
<gnucode>whoops soory for that last message.
<gnucode>I just ran the command emacs -q . And I am just trying to send email via C-x m. Emacs can be a bit difficult to get email set up and working.
<unmatched-paren>kabouik: It's reasonably simple
<unmatched-paren>you clone the guix repo
<unmatched-paren>make a branch
<unmatched-paren>add your package (probably in gnu/packages/mail.scm)
<unmatched-paren>make sure it passes guix lint
<unmatched-paren>commit the package, with a commit message following the project conventions
<unmatched-paren>and run `git send-email HEAD^ --to`
<unmatched-paren>to send the last commit as a patch to guix-patches
<kabouik>Thanks a lot. Is that written somewhere else than just here on IRC?
<unmatched-paren>note that if you wanted to send multiple, you'd send a preliminary package, wait for debbugs to reply with the bug number, and send the rest to
<unmatched-paren>otherwise each patch would get its own bug number
<unmatched-paren>kabouik: It's here
<unmatched-paren>Also, to test packages in the guix repo,
<unmatched-paren>`guix shell -D guix`
<unmatched-paren>inside that shell: `./bootstrap && ./configure --localstatedir=/var && make`, and do `./pre-inst-env SOME-COMMAND-HERE
<unmatched-paren>you might need to `make clean-go` from time to time, the autotools (bleugh) setup isn't great
<kabouik>"reasonably simple", then pulls a dozen of commands I've never used :p
<sneek>atka: Greetings
<unmatched-paren>kabouik: `git send-email` just sends commits as patches, `guix shell` creates an isolated environment with packages installed (`-D` installs the dependencies of a package instead; it's short for --development), `./bootstrap && ./configure blah && make` is standard Autotools procedure, and `./pre-inst-env` is a little script to run commands in an environment where the guix command refers to the local checkout rather than your latest pull
<kabouik>I really appreciate your patience unmatched-paren, thanks a lot.
<kabouik>I see that mail.scm is not alphabetically sorted, so I just put mine at the end I assume?
<unmatched-paren>kabouik: If you need to make a new version of the patch, make the changes, do `git commit --amend` (or an interactive rebase `git rebase -i` for multiple commits) and then `git-send-email COMMIT-RANGE^ --to -v2`
<unmatched-paren>replacing -v2 as necessary
<unmatched-paren>COMMIT-RANGE could be HEAD^ for one commit, HEAD~1^ for the last two commits, HEAD~30^ for the last 31 commits, etc
<unmatched-paren>e.g. to amend my aerc patchset, which has 41 commits
<unmatched-paren>`git add -p && git rebase -i && git send-email HEAD~40^ --to -v6`
<unmatched-paren>also, you can add extra notes to the emails with `-a`
<gnucode>unmatched-paren : weird: (debbugs-get-bugs :submitter "me" :status "open") no longer works for me. It is giving me nil, but issues still shows that I have bugs open.
<unmatched-paren>well, i don't use emacs-debbugs, so i'm not sure why it's doing that :)
<gnucode>unmatched-paren: I've got no idea either. I'll hop over to #emacs
<kabouik> I'm not sure what to do with these. I read but still find myself a bit confused.
<nckx>kabouik: You have a custom 'check phase (?), which doesn't respect the #:tests? keyword (and hence modifiers such as --without-tests). Write it something like (lambda (#:key tests? #:allow-other-keys) (when tests? (do testing stuffs here))).
<nckx>The other 2 lines are not actionable.
<kabouik>Yes there's a custom check phase, as seen above with unmatched-paren, because it's using cmake
<nckx>kabouik: When files aren't alphabetically sorted, just put the new package above the first existing package that would come after it, alphabetically.
<nckx>kabouik: I'm looking only at your guix lint paste, not any code.
<kabouik> (list #:phases #~(modify-phases %standard-phases (replace 'check (lambda _ (invoke "ctest" "--output-on-failure")))))
<nckx>s/lambda/lambda*/ by the way.
<acrow>vagrantc: No, it's ok. Rewriting is good. For everyone.
<unmatched-paren>kabouik: Oh, yes, I forgot about that. You need to use the when tests? thing so that it respects --without-tests i believe
<kabouik>I am failing to convert the test phase you wrote into the format nckx advised above; really I just don't understand what those records/fields do here
<kabouik>And even though I have read about #: and ? and $~ a dozen times, there's so much I'm trying to understand on other fronts while trying Guile
<kabouik>So in the end just placing them in the right order, with the right brackets, and replacing the old snipped with the new without breaking things, is already quite a challenge with a lot of trials/errors
<unmatched-paren>which format?
<unmatched-paren>the (when tests? ...) one?
<unmatched-paren>basically, as i explained in the note, that (lambda _ ...) is called to run the phase
<unmatched-paren>sort of like this:
<kabouik>Yes, that one
<unmatched-paren>(phase-func #:inputs blah #:outputs blah #:tests? blah ...)
<unmatched-paren>because we're just binding the entire arg list to _, we're basically ignoring these
<unmatched-paren>but to recieve the keywords properly, we need to use guile's lambda* extended lambda form
<unmatched-paren>(lambda* (#:key tests? #:allow-other-keys) ...)
<unmatched-paren>we recieve and bind the #:tests? argument passed to the function
<unmatched-paren>#:allow-other-keys stops it from complaining that other keys than those that have been specified have been used
<unmatched-paren>then you simply wrap the contents of the phase in (when tests? ...)
<nckx>It might help to know that apart from the ‘(do testing stuffs here)’, nothing in my example was pseudocode.
<nckx>+ the missing ‘*’ typo.
<kabouik>so (lambda* (#:key tests? #:allow-other-keys) (do "ctest" "--output-on-failure")))? Really I don't know what I'm doing with this line, they're all potato to me (I swear I'm trying, but I'm not a programmer, not even in another language)
<kabouik>Just some R for work and Bash as hobby
<nckx>(when tests? (invoke "ctest" "--output-on-failure"))
<unmatched-paren>kabouik: Your lambda part is right
<nckx>WHEN is like a single-branch IF.
<nckx>If the predicate is false, the body is simply skipped.
<unmatched-paren>(mhen COND EXPR ...) = (if COND (begin EXPR ...) #f)
<unmatched-paren>or, (define-syntax-rule (when cond expr expr* ...) (if cond (begin expr expr* ...) #f))
<nckx>s/predicate/condition/ you are a rightperson.
<nckx>I'm sure this is all helping and not confusing kabouik further 😃
*kabouik is in foetal position, crying.
*nckx wraps them in a soothing WHEN blankie.
<unmatched-paren>Basically, where if treats the first expr as a 'then' branch, and the second as an 'else' branch, when treats all the expressions as 'then' branches.
<unmatched-paren>So that you don't have to write that pesky begin form.
<unmatched-paren>(begin just evaluates/executes/... each expression inside it in order, like a let that doesn't bind any variables)