<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: https://github.com/jarun/nnn: invalid Git URL replacement specification" <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. <yewscion>kabouik: exit should work, so should C-d. <gnucode>i am starting to wonder if you can run sway inside qemu...it 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>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' <apteryx>"Authenticating commits 9edb3f6 to 525688e (39,006 new commits)..." wait, what? <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>There's one issue though: guix download https://github.com/d99kris/nmail 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>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 https://github.com/d99kris/nmail' 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>') <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? <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. <rekado>wingo: I also use Gnome, but I don’t see this problem. I rarely ever reboot; always suspend and resume. <wingo>also. trying to upgrade a guix-on-ubuntu system i just got: <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 <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 <unmatched-paren>rgherdt: I, uh, --was enlightened-- switched to emacs since I said that :P <rgherdt>you'll never come back, I also did that years ago <rgherdt>someone else wrote to me offering help to add support to neovim, I'll contact him again <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>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 <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 ***wielaard is now known as mjw
<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"))) *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]>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! <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 <civodul>i spent the morning reviewing patches, i can't work any faster, sorry! <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>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>you can spin up a guix vm with just the package manager <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>though i don't think the installer lets you pick which filesystem you're going to place the directories <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>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>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 ***zgcarvalho40 is now known as zgcarvalho
<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 <iyzsong[m]>if you are migrate /gnu, just mv /gnu/store into another fs then mount back. <pkill9>ah nice, it copies them recursively ***Xenguy_ is now known as Xenguy
<davidl>unmatched-paren: yes re: paste thing. I forgot, sry. <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 https://p.teknik.io/Simple/25Owy 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>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>so you can see the build output in one frame and the other frame shows the overall progress <ulfvonbelow>kabouik: you're welcome, and regarding https://p.teknik.io/Simple/2SOwy, 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. <kabouik>I think there should be tests since the nmail devs provides a make.sh script that takes a `test` subcommand. Looking at the script, make.sh 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. <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]>I guess it needs the qtbase arg added somehow <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" <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 <podiki[m]>ah, I see others do it but with explicit "wrap-qt-program" call *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 *apteryx tests fixes on them <podiki[m]>odd, did not get that email in my inbox despite being the original submitter <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? <apteryx>unmatched-paren: probably some module import dependency loop <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>No variable named tar in #<interface (gnu packages base) 7f8d93782d20> <apteryx>podiki[m]: I pushed a956c7df87 to fix bitmask, hime, hime, nimf and vorta <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 <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 <gnucode>It queries debbugs to show you all of the open bugs that you have personally have submitted. <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 <gnucode>unmatched-paren what do you mean by redundant? <unmatched-paren>gnucode: You could use (apply #'debbugs-gnu-bugs my-bug-list) I believe <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>may you remind me what apply is better than eval here? <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 <gnucode>unmatched-paren that's another good tip! <unmatched-paren>(apply #'debbugs-gnu-bugs (debbugs-get-bugs :submitter "me" :status "open")) <gnucode>yup! I just changed it! Thanks! you're a genius! <unmatched-paren>Nothing of the sort. Most peopl here are orders of magnitude smarter than me. <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 ? <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
***Dynom_ is now known as Guest8760
<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>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>Though I don't understand why it'd try "test"; I thought "check" was the default. <kabouik>I guess that would justify a "#:tests? #f ;;No tests included with sources"? <kabouik>Right, just found the typo too, good catch <kabouik>The sources include a make.sh with a `test` subcommand, but this essentially runs `ctest --output-on-failure` <kabouik>Maybe I can try `#:test-target "ctest"`? <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>This seems to compile fine with that (so far; it's not over yet) <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 <unmatched-paren>If you want to submit this package, you should probably be using a release tag instead of an arbitrary commit <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?) <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>v6 modifies go-notmuch to directly refer to the notmuch.so and notmuch.h files, instead of simply propagating notmuch <unmatched-paren>gnucode: Sadly, it's a Go package, which explains the ridiculous number of patches :) <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.... <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. <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>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>I don't think many people would write a Wayland application with their bare hands. <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: 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. <gnucode>unmatched-paren you could create a #lang hardened-guile <gnucode>unmatched-paren probably true. :) have you been using aerc then? <gnucode>unmatched-paren is it nicer than Emacs ? <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) <kabouik>But then that means guix build -f is pretty much deprecated? <acrow>vagrantc: full re-write is in progress. <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 <kabouik>That implies adding the package name at the end. Does that pass the standards for package inclusion? <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 <kabouik>I altered both the commit and the hash <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>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>I'll try just checking out the commit of the release instead of the tarball <kabouik>Right, so guix download sends correct hashes for files only, else on git it'll download an html page I assume <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 download` basically does the equivalent of `url-fetch` and hashes that <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 <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 <kabouik>Could (file-name …) alter the hash the .scm file is calculating? <kabouik>a03a09 is the hash of the release 3.74 <kabouik>And 1df16 is the hash guix hash . -rx gives me after checking out this commit in my /tmp/nmail <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 <kabouik>That's the one I want. Can you show me how you got it? <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 make.sh script to install from sources <kabouik>I clone the dir yesterday and probably experimented with the non-guix procedure to install it and see what make.sh was doing <kabouik>Now I checkout to the release commit and it didn't error out, I simply forgot about the build/ directory <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 <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 <yuu[m]>so #guile:libera.chat shadowbans matrix.org? <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 <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. <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. <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 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 <unmatched-paren>I've seen "[ 24.481911] udevd[177]: no sender credentials received, message ignored <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: https://p.teknik.io/Simple/gmXGS <kabouik>Now I'll check how submissions are done. <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>commit the package, with a commit message following the project conventions <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 XXXXX@debbugs.gnu.org <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 <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 NNNNN@debbugs.gnu.org -v2` <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>`git add -p && git rebase -i && git send-email HEAD~40^ --to 55903@debbugs.gnu.org -v6` <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 <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>basically, as i explained in the note, that (lambda _ ...) is called to run the phase <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>#:allow-other-keys stops it from complaining that other keys than those that have been specified have been used <nckx>It might help to know that apart from the ‘(do testing stuffs here)’, nothing in my example was pseudocode. <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")) <nckx>WHEN is like a single-branch IF. <nckx>If the predicate is false, the body is simply skipped. <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>(begin just evaluates/executes/... each expression inside it in order, like a let that doesn't bind any variables)