<RavenJoad>I'm not 100% sure. You have a pretty deep gexp nesting, and I always need to double-check the final result manually when it gets that way.
<lechner>RavenJoad / thanks! I did check and you are right that it may not do what I want. #$output is substituted as ((@ (guile) getenv) "out") which does not strike me as correct. (i expected a string.) the inputs is completely untouched in my output, too. i was hoping for a list of strings
<lilyp>((@ (guile) getenv) "out") evaluates to a string
<RavenJoad>The #$output looks right from the lambda*'s side, despite it not being what you want. Just the wrong amount of substitution.
<RavenJoad>#$inputs is probably just not the symbol you want? I am not sure how to gexp-escape to get the package's inputs.
<lilyp>note the labels that get added to inputs – it is not simply a list of strings
<janneke>rekado: it semes that java-rdf.scm is missing from gnu/local.scm
<janneke>rekado: make that missing from gnu/local.MK, of course :)
<dcunit3d>i'm trying to build a tree-sitter grammar for TCL, but there's not a recent tagged revision. it uses mercurial. here's the relevant package definition and build log. there is a clone of the code on github, but the actual upstream is on hg.sr.ht. https://0x0.st/HVL1.txt
<dcunit3d>i think it's having a hard time downloading the changeset/rev
<dcunit3d>well, i'm trying to use the github clone now, but for some reason, not all files are on that branch. it's still failing when running `tree-sitter generate --no-bindings` ... i'm not sure what I'm doing wrong. i'm trying to just build it manually now
<dcunit3d>i want a decent TCL environment in emacs bc i want to try scripting OCC (open cascade, which is what FreeCAD is based on)
<dcunit3d>OCC has like thousands of test examples written in TCL, which is built in to the project. there are some scripting options for python and other languages, but AFAIK only TCL is really built into the project
<dcunit3d>also, there's this number in the geiser repl: "scheme@(ellipsis packages tree-sitter) >" it makes me feel like i have a really bad golf score
<dcunit3d>is there a better way to decrement it other than to repeatedly enter `,q` ? it seems to indicate that i'm dipping into another backtrace
<dcunit3d>ok, well i got it to build from the hg source. i'm hoping it will work fairly transparently in emacs. i'd like to experiment with a tcl-ts-mode and then maybe an ob-tcl mode that communicates with a OCC repl session.
<dcunit3d>it would all constitute a F/OSS means of building _simple_ STEM files for 3D printing. the STEM files could maybe then be distributed as packages that would work in pretty much any CAD (instead of going to weird sites to download zip files where the downloaded assets are specific to one CAD software)
<dcunit3d>i donno if i'll get through all of it, but i'd like to try anyways. i would probably use it, but i'm pretty sure any complicated designs, it wouldn't work well.
<Kabouik>So babarivière fixed the guix-emacs channel and I was able to guix pull and initiate a package update with it, but now I'm getting an issue which I think is related to Guix itself. At some point in the update/compiling process, it fails and complains that my system is read-only (which it is not, but somehow it stalls during the update). I did it twice in a row and both times, it failed when compiling qemu. Unfortunately I cannot show the logs or even
<Kabouik> a screenshot because when it did, nothing would work on the system, not even the clipboard, let alone IRC. Next time I'll try to take a picture of the screen. But for now, wondering if that may be a known issue?
<cbaines>I've just deployed a new "Mark patches as reviewed" feature to QA, which should simplify tagging patches with the guix reviewed-looks-good usertag
<cbaines>let me know if you're interested to try it out?
<nckx>Kabouik: I also had to rebuild QEMU but it built fine. I also built it on berlin, where it also succeeded, so there should at least be a substitute. Pity we don't have your logs but glad it eventually worked.
<nckx>Once you think about it, successful builds overwriting the logs of older failed ones is not that obvious a choice. Oh well.
<zamfofex>Regarding the Debian licensing issue: I remember once mentioning I didn’t want to include Agda stdlib code in my website. When people asked me *why*, I said it was because it would break their license. People seemed confused about how (since it was Expat or a variation thereof), and I said that it required including a copy of the license, which by default the Agda HTML generator did not, and they just told me no‐one actually cares
<zamfofex>So I guess while technically disallowed, it’s unlikely to cause any legal issues, because the intent of people licensing their programs in permissive licenses is to allow others to use those programs as they seem fit without constraints. (Which is partially why I think the Expat license is kinda awkward, and I think 0BSD would be a better fit for that intent.)
<nckx>There's a licence document stating their intent. We can't ignore said intent merely because its convenient for us, or because a non-zero amount of people don't choose their licence carefully. Plenty do.
<nckx>‘I would like attribution in derived works’ ‘Lol no you don't nobody cares’ is still a power play, even done by an obscure distro that nobody will sue because it's not worth it.
<nckx>(Projecting on Guix here, clearly not Debian 😛)
<zamfofex>That is fair enough. I’m sure someone might legitimately take issue against that. However, I think that’s the minority, I feel (which I’m not saying is negligible at all). From what I see, most people are in the mindset of “I want to allow people to use my program without hassle”, and they just pick Expat because it is popular.
<nckx>Right. Non-zero could be high! It's hard for me to enter that mindset, but we're a special bunch around here. I can certainly imagine this happening if you get sucked in through the GitHub end of open source. ‘Ooh, I can choose between Expat *and* MIT? Free at last!’
<bienjensu>An emacs package relies on `curl` and `mpv` to function, and its tests fail without these executables being present. How should they be added as inputs to the package?
<lechner>yes, my program gets a modified hashbang at execution time. it would be unrelated to the patches you mentioned
<Kabouik>Anyone comfortable interpreting this emacs native-compile-log? https://0x0.st/HVpG.txt After I ran a guix package -u, and restarting my emacs daemon, it would only load part of my init file (some things not being working as they should with my config). After finding an issue with "native-comp-deferred-compilation-deny-list", I decided to delete my ~/.emacs/straight folder to start fresh for the few packages that may be installed from it. Then I got
<mirai>attila_lendvai: my only comment on that is perhaps find out the reason for “FIXME: Determine why these tests fail” ?
<Kabouik>So do I understand correctly that everyone is having issues with emacs-next/emacs-next-pgtk if they have upgraded it recently, until those patches are merged? I'm sure I am not understanding correctly.
<attila_lendvai>mirai, i have inherited most of those. and while i'm not a python expert, those failures are probably bugs in the test framework, or the tests themselves.
<mirai>since “FIXME: _non-trivial task_” often never happens
<nckx>Kabouik: That is my understanding. I'm still on emacs-‘next’-pgkt 29 myself.
<mirai>hmm… have you forwarded the logs + open bug report with upstream?
<attila_lendvai>mirai, life is short. the app functions properly, and certainly much-much better than not even compiling, or not being packaged for guix... :)
<nckx>make: *** No rule to make target 'etc/guix-gc.timer', needed by 'all-am'. Stop.
<mirai>attila_lendvai: right, I understand that though I'm one for getting upstream involved when possible. It pains me to see so much patch/workarounds (i.e. duct tape) done in Guix packages
<mirai>by all means do patch things in the meantime, just let upstream know so that hopefully we can get rid of the hacks someday
<mirai>less hacks makes things easier to upgrade/maintain in the future as well so I count the extra reporting work as a long-term investment
<nckx>And at least include a link to the upstream bug report as a comment in Guix. Trivial for you, saves a lot of work for others.
<attila_lendvai>i haven't even looked, because my impression is that upstream is a web of patchwork in itself... but lemmesee!
<Kabouik>If I don't feel up to the task of fixing emacs myself before some people with more Guix intelligence than me actually merge a fix, would reverting my Guix upgrade with a `guix package --switch-generation=xxx --install` get me out of trouble? There is never a good time to fix things, I know, but now is one of these instances of "not a good time".
<nckx>There's --roll-back for the common ‘-1’ case, but yes, that would have worked for me. I don't know your set-up :)
<Kabouik>I installed a couple other things when trying to investigate around straight-el so -1 won't work, but I know what was my last working generation.
<bjc>you know what would be nice? being able to assign a name to a generation
<bjc>like, before i do some system updates on other machines, i'll ‘zfs snap tank@something-meaningful-to-me’
<nckx>Aha. Commit 69f6edc1a8596d2cb4c67e0435d35633af6f3cbc meant to fix a bug, but now implies rm -f etc/guix-gc.timer .
<Kabouik>nckx: not really, I would just like to restore the state of my emacs before I upgraded it (and a million packags for it) with `guix package -u`. Now I just ran `guix package --switch-generations=670` but that didn't change the binary in use for emacs, so I assume there's something else to do to fully revert to that generation.
<attila_lendvai>mirai, not really. there's considerable impedance mismatch between my way of working and the guix expectations. e.g. i'm quite frustrated by the strict demands WRT the detailed changelog format in the commit messages (inherited from the CVS times, i guess). i don't want to join the committers neither to lower the standards, nor to frustrate the other maintainers.
<attila_lendvai>mirai, i'm working on lowering the impedance mismatch, both by lobbying for a more reasonable expectations (from my point of view), and also looking for arguments to convince myself that the standards actually provide balanced value for their implied costs.
<mirai>heh, I confess that the message format is the unfun part and I personally tend to leave that as the last thing to do (I write some quick messages and rebase/reword everything in the end)
<mirai>serves as the last check before sending them out to ML
<mirai>tho the messages have been occasionally useful in narrowing down what went wrong with certain changes
<attila_lendvai>mirai, my problem is not so much that it's not fun, but that i find it way more expensive than the value it provides. and as stated above, nothing demotivates me more than a sense of futility... when i work more to format and send a patch than working on the patch... then i stop to wonder...
<mirai>tho in some cases it's almost useless (try finding out what's the fate of the docbook-xsl-next package/variable)
<pastor>Good evening. The other day we were talking about the issue where due to the disign of the `guix descrive` API emacs-guix is not able to fetch user defined channels for packages. I've tried to make some changes to fix it and submit a patch to no avail. Could someone give me some hints on what would be the best approach? I don't mind spending some time to submit a patch.
<mirai>perhaps there's some gitfu I'm missing but the changelog format surely didn't capture this change
<mirai>attila_lendvai: for large series I think it's alright since it serves as a moment to revise the changes
<nckx>Sure it does. For example, ‘(docbook-xsl-next): Delete variable.’ would have covered it.
<mirai>for small changes, dunno… perhaps some combination of snippets & emacs-fu?
<mirai>or higher S-exp diff based heuristics that can churn out a reasonable commit message
<mirai>nckx: right, I worded that incorrectly. What I meant to say is that the removal of that variable went undocumented
<nckx>‘current’ *is* generally the system that's providing most of your, er, ‘currently’ running system. But the kernel is an exception, and you're asking about something rather odd (mapping grub menuentries in the past back to… something).
<nckx>I don't even understand what you're trying to do but it's an unusual use case.
<nckx>You lost me. The wc -w was to set the scene, but substitute wc -c if that's more clear.
<nckx>It's not triggered by word boundaries. If it happens on one, that's a jolly coincidence.
<lechner>the wc is not helpful. as you pointed out, Linux does not split the second argument
<lechner>how many arguments does any interpreter receive when invoked via a hashbang?
<attila_lendvai>mirai, nckx, FYI, this rather quickly finds the removal commit in a pager: `git log --grep docbook-xsl-next --patch`. which means that i'm still looking for a reason for the detailed ChangeLog format... :)
<pastor>nckx: did you have any time to hack on the emacs-guix issue we were commenting last day?
<nckx>followed by (currently) /gnu/store/4gvgcfdiz6uuuuxxxxxxxxxxxxxxpv5-guile-3.0.9/bin/guile (because I edited it)
<nckx>I didn't feel like keeping going in circles, so I remounted my store rw to make my point.
<attila_lendvai>nckx, i didn't say it's useless. what i'm saying is that if you sum up all the time spent on writing those commit messages, then it's way more than the decrease they cause in time spent searching. IOW, it's not worth it.
<civodul>janneke: ISTR you fixed “rewrite-url, without to-version” recently, no?
<attila_lendvai>nckx, for one, there are mutliple people complaining about it on the mailing list. plus, if our ultimate goal is a well functioning community, then we should try to ensure that its members work with high efficiency, which translates to getting rid of rules/habbits that are not a net benefit.
<lechner>nckx / thanks! i saw that and have a work around that all of Guix may appreciate
<somenickname>nckx: I just want to look at the GRUB config. Nothing more just reading
<nckx>So is there another question I'm missing, lechner?
<lechner>attila_lendvai / i'm not sure there is a point in arguing here. you are a skilled communicator and are better off making your case on the record via email. you will expose the collective attachment to precedent
<janneke>attila_lendvai: they are, that's what that script is for
<nckx>It looks like you're looking for an argument, so I'll back out.
<vagrantc>i mean, technically, is there anything preventing guix from using btrfs snapshots or something to actually do filesystem level snapshotting? it is somewhat redundant ... but not entirely (e.g. upgraded versions of things mangling dotfiles in your homedir in incompatible ways
<vagrantc>i guess you'd need the machinery to boot into an older snapshot...
<old>where does sherpherd logs go for home configuration?
<old>I do not see my mcron job log anymore getting called
<nckx>sneek: later tell somenickname: Not much, but enough to learn that it's very likely a race condition in configuring PAM (so naught to do with Shepherd services or Guile modules) that can be worked around with (login-pause? #t) for now.
<PotentialUser-47>so some of the stuff in the description-s of how guix~s management of the file system seems as if it would require a custom filesystem, does guix use a custom filesystem, something like fuse or does it just use the "default" ( ig) filesystem
<bjc>guix bind-mounts the store so it's tough to access outside the guix daemon. everything else is as standard as standard can be, and you can choose the underlying filesystem of (almost) everything
<bjc>there are some issues with activation ordering during boot, so you pretty much have to have /gnu/store, /run, and / on the same filesystem (and maybe others, i'm not sure), but otherwise you're good
<bjc>there is a way to tmpfs-mount / while preserving a persistent store, but that's not generalizable
<PotentialUser-47>was wondering about a function like `directory-union` which seems like it could not be achieved with just symlinks so maybe the guix project is maintaining a custom filesystem manager which allows directory unions without copying any files