IRC channel logs
2023-09-27.log
back to list of logs
<rekado>I think it would be great if we had such a VM image <rekado>janneke: I wonder if the splitting of .go files perhaps resulted in gnu/packages/java-rdf.go getting dropped <rekado>in a fresh VM with a fresh git checkout I see that java-rdf.scm never gets compiled to a .go file. <nckx>Noisytoot: Thanks. Yoink time. <bjc>oh good. i've managed to make my user shepherd unresponsive <nckx>Your badge is in the mail. <nckx>(The ‘user’ part is a new one, to me.) <bjc>it got stuck starting a service somehow. but at least that's a hint <bjc>i know ludo added a separate ‘starting’ phase a while ago, and i've always kind of wondered what that meant <lechner>Hi, is Python 3 in guix known as 'python' or 'python3', please? <nckx>The package variable is python, the (full) spec python@3, so python works too, and the binary is python3. <nckx>The choose your own adventure of answers right there. <bjc>i stuck my fingers in the manifest pages so i can find all the endings that end in (ice-9 boot) <nckx>You have died of dysentery: Success. <bjc>that makes me want to write a themeable boot service <lechner>Hi, is there a G-expy way to refer to the list of all inputs, please? <ulfvonbe`>it seems that running 'guix system roll-back' clobbers bootloader options <ulfvonbe`>for example, I use a custom bootloader that adds a second initrd with a luks passphrase, and after running 'guix system roll-back', I had to enter the passphrase twice <ulfvonbe`>I'm lucky it at least didn't clobber the installed grub, since that would have made booting impossible entirely <ulfvonbe`>since the default grub install fails to detect that I'm using mdraid + luks + lvm <RavenJoad>Has anyone tried using Guix system on a Thinkpad X13s? The Snapdragon ARM one. <apteryx>rekado: would using --sysroot gcc option help? <apteryx>have the compilers self-contained when it comes to their own include directories at least, instead of possibly clashing together (because they share the same environment variables) <lechner>ulfvonbe` / Hi, I rewrote some of the bootloader mechanics recently. Will you please share your configuration? <lechner>ulfvonbe` / rewrote, but did not submit to Guix <ulfvonbe`>it's pretty nonstandard, involves a custom bootloader, as in (bootloader my-grub-luks-efi-bootloader) <lechner>i'd be happy to read it, if you are interested in sharing <ulfvonbe`>not at the moment, maybe after I clean it up a bit <lechner>Hi, the first reference to inputs here works, but the second inside program-file via #$inputs fails. Why is that, please, and is there a fix? Thanks! https://bpa.st/UW4Q#1L22-L22 <RavenJoad>lechner: If it is the #$inputs in the (cons ...), I think it is because inputs is the symbol in the lambda*, and is not substituted from Guix host to the builder. <lechner>RavenJoad / thanks! is there a way to accomplish it? <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) [6]>" 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? <janneke>aitzkora: isn't that a bsd-2 license? <aitzkora>I could compare with a bsd-2 standard text <aitzkora>janneke : you're right it's the same text! I will bsd-2 license <Kabouik>My guix package -u finally worked; I guess that during the two previous attempts, my CPU was throttling and causing issues or something. <efraim>sneek: later tell zimoun I'm looking at the julia stuff again, should lapack be an input for openblas? <efraim>sneek: later tell zimoun I'm looking at the julia stuff again, I think we might need to change the pkg-config file for openblas-ilp64 so it doesn't overlap (-lopenblas) directly with openblas <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? <zamfofex>bienjensu: Do you mean ‘inputs’ vs. ‘native-inputs’? I think ‘inputs’ is more suitable here. <bjc>since the variable is likely customizable, i think ‘propagated-inputs’ is probably more appropriate <bjc>does it also patch the .el file to point at it? <bjc>i guess that's the answer then =) <nckx>As a bonus side note: even #:tests? #t won't run tests when cross-building, so test-only inputs don't need to be (also) native. <bienjensu>Considering disabling tests as mpv isn't directly called in the package (only through emacs-mpv) and curl isn't called anywhere afaik. <bienjensu>I think emacs-elfeed is missing a curl input. <efraim>it looks to me like elfeed-curl.el should have elfeed-curl-program-name substituted to the full path to curl, if it isn't already <lechner>Hi, does GNU Guix touch the interpreter directives in hashbangs in any way, or are they delivered to the interpreter verbatim, please? <nckx>Can you be (a lot) more specific? Some/most Guix build systems patch shebangs, sometimes more than once. Not all do. <nckx>(If you're curious, grep for patch-shebangs.) <nckx>But by my definition, these are still ‘delivered to the interpreter verbatim’, because that sounds like a run-time choice of words. <nckx>There's no interception or other weirdness. <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 <nckx>lechner: Then we'll need more info. <mirai>what's up with the new bootstrap script + configure? <mirai>I get this in the `git status' <mirai>Changes not staged for commit: <mirai> (use "git add/rm <file>..." to update what will be committed) <mirai> (use "git restore <file>..." to discard changes in working directory) <attila_lendvai>mirai, i used to see that months ago. it may also be due to some state in your checkout. <mirai>I'm starting to see it “recently” O.o <nckx>There is no ‘new bootstrap script’. <mirai>but yeah, its frustrating when removing worktrees or doing rebases <Kabouik>What would I need to install to fix the gcc native compilation issues in the Emacs logs above (which I think are related to straight.el)? <bjc>i'd guess you need gcc-toolchain <bjc>doesn't emacs-next already include it, though? <nckx>What makes you think you need to install something? <Kabouik>Nothing really, I'm just surprised to have so many native compilations issues, but I don't really understand how those native compilariosn are done. <nckx>Untested (by me), but looks promising. <Kabouik>What I use is emacs-next-pgtk, would it apply to it too? <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[2]: *** 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>I need to follow-up the --switch-generation with a --install, right? <nckx>If you want to install something. <lechner>nckx / are you on a computer or on a phone? <nckx>lechner: But seriously, what's the end goal? <nckx>I'm in the shell, now what? <lechner>please type head `which guix-helper-bot` or equivalent <mirai>why not let 'patch-source-shebangs do it automatically for you? <nckx>lechner: And thanks for the bot-wishes. <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. <nckx>Are you running a daemon or so? <nckx>You can double-check with ‘realpath $(which emacs)’ or so. <Kabouik>I am, but killed already before switching generations. <user363627>I am new to guix and am interested in converting a Dockerfile I have to a guix manifest. What's an easy way to do this conversion or how do I get started? <Kabouik>Or maybe I was already running emacs >30 before and had no issue. <lechner>mirai / i use 'env' in development shells when working on my Guile programs. our 'patch-shebangs does not know about -S <Kabouik>Everything back to normal after restoring the old generation nckx, thanks. I was just concerned by emacs --version, but seems >30 was still working at this stage of the previous generation. <Kabouik>Thanks for showing me that the issue was already posted on Guix issues, this helped me understanding that it was not in my config. <lechner>nckx / after you wake up, please run guix-helper-bot and have a look at the error message. the hashbang passed to preambled-exec was changed <mirai>how do I use yasnippet to insert me a template for a package object? <mirai>I assume .dir-locals.el already took care of loading the snippets and whatnot <bjc>turn on ‘yasnippet-global-mode’ if you haven't <bjc>after that, i think it just registers as a capf backend, so it should work with your existing completion keys <mirai>right, so the question now is… what are the “default” completion keys <mirai>well, I see that C-c & C-s does something <mirai>thought it was an autocomplete kind of thing where (pack… would autocomplete into (package … … …) <bjc>i swapped mine so long ago. iirc M-/ works for completion by default <bjc>hrm. that might just be for dabbrev <mirai>ugh, what was that website that allowed you to search a package across multiple distros <mirai>and gave package counts per distro <attila_lendvai>it's very frustrating that i have to keep rebasing my contributions that are pending forever... and to see that someone does the same work that i have done and sent *months* ago... <attila_lendvai>and then it needs to be argued that the current infrastructure (looking at you debbugs) is insufficient <dthompson>somewhat recently had a patch merged that I sent like a long time ago and had forgotten about. <attila_lendvai>python daemon was failing to build for *months*. i have sent a patch series that fixes it, which now needs to be rebased... <dlowe>that reminds me that I need to see if I can fix the django package <dlowe>is it just me or is there an off-by-one bug in the number of columns computation for guix pull progress bars <dlowe>it used to be worse, now it just looks like "updating substitutes" is affected <dlowe>nope, ungoogled-chromium makes it scroll <mirai>attila_lendvai: considered applying for commit rights? <mirai>solves the antecedent question, the lack of enough eyeballs for reviews <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) <mirai>it existed and then… ceased to be (???) <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 <somenickname>I started Guix from GRUB with the gen #11 but "guix system list-generations" shows I am on gen #13. Why? Shouldn't they be in sync? <mirai>somenickname: you booted #11 but the latest gen is still #13 <mirai>not dissimilar to `git checkout HEAD~3' <nckx>(Hence the two entries for /run/*-system/. <somenickname>Ah okay. How can I find the current GRUB config to see the entries? <somenickname>and if (current) doesn't mean current booted gen, what does it mean then? <nckx>Hacky idea: ls -l /var/guix/profiles/system-*-link | grep $(realpath /run/booted-system) <nckx>somenickname: It means the current default system, which is usually the newest. <nckx>‘booted’ is contant during an uptime. ‘current’ can move around, for example each time you run ‘guix system reconfigure’. <nckx>You don't want, e.g., kernel modules upgrading from under your running kernel. <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>Concentrated concentation concentrate. <nckx>If I'm going to be staring at magically differing hashes in shebang lines, I need to be in the mood. <lechner>not the hash, the number of arguments <attila_lendvai>nckx, mirai, any insights on why `git log -Gdocbook-xsl-next --patch` doesn't show the commit that deleted it? (besides it being rather slow with zero feedback about its progress...) <nckx>I'm going to say ‘merge commit’. <nckx>lechner: From what I remember earlier (and a little help from bash): you wanted me to look at head `which guix-helper-bot`. <nckx>OK, I did, clearly broken shebang. <nckx>λ head -n1 `which guix-helper-bot` | wc -w <nckx>Unless I'm missing something, you can't have 8 arguments in a shebang. <lechner>sure you can. they just get passed as one <lechner>the issue is elsewhere. do you see -e main -s ? <nckx>I do not expect to see -e main s, since it's near the end. <nckx>*-s, but you get the point. <nckx>If you want to flirt with buffer overflows, prepare to get your heart broken. <nckx>This is one of the few drawbacks of Guix, those pesky long file names ☺ <lechner>the character limit for Linux command lines is two million, except it includes the environment <lechner>doesn't the head command show -e main -s ? <nckx>Yes, and that's what's falling off the end of your buffer. <nckx>I don't know where you got this 2 million figure from, it's bogus. <nckx>I'm not going to try, but I bet if you shorten ‘no-auto-compile’ you'll see -e main -s magically appear in your error message. <lechner>now please execute guix-helper-bot inside guix shell -f file <nckx>I think Guix's only involvement here is lengthening your 9 word shebang of doom to something that shows this limitation. <lechner>the command will fail and print the command line it received <nckx>Hence everything I typed above. <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... :) <nckx>attila_lendvai: So people don't have to wade through noisy machine-generated diffs. <lechner>nckx / thanks! what is the third argument in each of these? "/gnu/store/y9fj43mqs8vxbyihca1v2gy3fygm035c-profile/bin/guix-helper-bot" <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? <nckx>attila_lendvai: And I disagree. <civodul>i tried to update ‘guix’ on master but i get getaddrinfo-error on that test <avalenn>nice to have a Guix meeting in Île-de-France tomorrow :-) ! too bad I cannot attend :-( Hope for next time. <lechner>nckx / isn't there an extra argument at the end (after the unsplit second argument) <nckx>attila_lendvai: I mean, you'll have to come up with something more convincing than that if you want to convince others. <attila_lendvai>nckx, how is my above pasted git log --grep command less efficient than grepping for the changelog entry? <civodul>janneke: awesome, thanks! i’ll take a look hopefully later today <nckx>attila_lendvai: I don't know, how is it? If it's not less efficient, why ask me how it is? <attila_lendvai>nckx, and remember, i'm not nitpicking here! i'm also looking for convincing arguments so that i can quiet the annoyance i have while i'm writing the changelog entries... <lechner>ACTION likes attila's approach to problem-solving <janneke>when that's fixed, i'd like to make/have an update'd-guix-package so that we may finally run guix pull in a childhurd <attila_lendvai>nckx, well, you sound like arguing *for* keeping the changelog format. pardon me if i misread you. <janneke>civodul: oh wait, ah no -- we prolly also need your smart-hurdloading patchset first :) <janneke>moving targets and dependencies, terrible :) <nckx>Not so much arguing for, as not understanding why we should drop it without clear advantage or replacement. <janneke>"<janneke> rekado: it semes that java-rdf.scm is missing from gnu/local.mk" fixed first too <nckx>I have plenty of experience with diffs to know that they aren't a replacement for change logs. <nckx>lechner: The arguments following it are ‘--no-auto-compile -e main -s’, see my paste. <janneke>ACTION wonders now if they should mention that explictly to rekado- too... <nckx>lechner: You'll see ‘-e main -s’ sliding into view as I shorted the guile directory. <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>what about the third argument, please? <attila_lendvai>nckx, i agree that in some cases the diff is not a replacement of a well written changelog entry. but this probably doesn't apply to 90+% of the current commit messages. <nckx>somenickname: Well, if you're just browsing grub.cfg, take a look at the gnu.system= kernel arguments. <lechner>attila_lendvai / your method is a lot more general, i.e. it can look for more stuff. plus, it is much less work to maintain <nckx>lechner: Can you please just tell me what you expect to see? The third argument is ‘--’, as said above, so we're clearly not counting arguments the same way. <attila_lendvai>ACTION will learn all the ins and outs of git log --grep and eventually write up an argument on the mailing list <nckx>ACTION wonders how ‘git log --grep’ is related to change logs. <nckx>I was looking *at* guix-helper-bot. <nckx>/gnu/store/y9fj43mqs8vxbyihca1v2gy3fygm035c-profile/bin/guix-helper-bot is the file I am editing, yes. <attila_lendvai>nckx, so that 90+% of the changelog entries are just rewordings of diffs that can be found trivially using git commands <lechner>attila_lendvai / actually, our changelog is very much in line with UN*X philosophy: it does only one thing, and does it well <nckx>Yes, shorter and more efficient rewordings. <janneke>attila_lendvai: in case you haven't already, you may want to check build-aux/gitlog-to-changelog <attila_lendvai>nckx, once again, what we are talking about is the difference changelog entries make vs. the cost of writing them. <nckx>somenickname: Ah, now I remember :) Yes, ‘old’ != ‘all’. <attila_lendvai>janneke, thanks! i didn't know about it. i only knew about 'C' in emacs/magit. <attila_lendvai>janneke, i read that url before. i think 'ChangeLog in a release tarball' is not relevant for guix, because the commit logs are not extracted into a ChangeLog file... or are they? <nckx>attila_lendvai: ‘once again’? <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. <attila_lendvai>nckx, i didn't mean to offend, but you sound like you don't care about its costs. i'm not arguing that it's useless. i'm arguing that it's not worth it. <lechner>let's not go for cheap shots but instead move in for the kill <attila_lendvai>lechner, good point! i need to pick the tomatoes anyway before the sun goes down... :) <janneke>attila_lendvai: some of us lived through several pretty breaking version control system changes (rcs, cvs, arch/tla/svn, git) <nckx>Oof, I consider myself lucky to have started at CVS. <janneke>one of the only constants has been change logs <attila_lendvai>lechner, no, it's been delayed for multiple days already... ;) need to put them in jars. tomatoes in the grocery store are crap... <lechner>janneke / they seem to come in different styles <attila_lendvai>janneke, it was certainly useful back in those days. but i don't see how it will ever be needed in a post git era. <attila_lendvai>lechner, well, post git in the sense that git is already there. not sure how to say that in english. <janneke>attila_lendvai: you might want to work on your imagination there ;) ;) <attila_lendvai>janneke, that's a good one as a joke, but not so much as an argument. <janneke>ACTION has seen lossage at every change and sees no reason why the next transforamion will be less painful? <janneke>but this is all beside the point, guix is a gnu project and so we use gnu commit logs <nckx>lechner: I'm aware that I am thinking and typing very slow. Is the whole shebang thing clear? <lechner>that's why when you hand us a problem we are sure to screw it up even more <nckx>I do not understand what you do not understand, and we are at an impasse. <lechner>isn't the hashbang supposed to deliver *two* arguments? <lechner>i should printed the argument count as well <mirai>HA! That's something to do with some standard (POSIX?) <nckx>Yeah, this looks like normal behaviour to me. <nckx>You're making some leap from ‘my shebang looks like this’ to ‘my process's running argv should look like this’. <mirai>whether in “#!/bin/foo -1 -2 -3 -4” the second argument is everything after “#!/bin/foo” <nckx>(Assuming this is argv you're printing; I didn't look at the code.) <nckx>mirai: Right, that was the issue above (together with a buffer overflow) but this is about the script name itself being appended. <lechner>mirai / i get that part. i did not realize that the third argument passes the name of the surrounding script <lechner>nckx / i know you are right, but what is Linux's ARG_MAX, please <nckx>Something like 128k, from memory? This is clearly not ARG_MAX, I didn't mean to imply that. <PotentialUser-47>hello i am lucy, are people here mainly people who often maintain the guix system? <mirai>lechner: Character interpretation <nckx>PotentialUser-47: Ditto. <nckx>This person who often maintains the guix system is going to take a nap, because this person who often maintains the guix system is groggy as #~#$. <lechner>PotentialUser-47 / we are happy to help while our wizard gets some rest <PotentialUser-47>i am mostly ok right now, spent a while figuring out why system reconfigure was pulling gnome but turns out it was gdm <nckx>If I am a wizard, which I dispute, I'm currently more Radagast than Gandalf. <PotentialUser-47>trying to create a package for the main branch of my favourite text editor "helix" <mirai>lechner: I wasn't in the convo from the beginning <mirai>so what's the issue here/affected part <lechner>mirai / from your knowledge of POSIX, how many arguments should an interpreter receive when invoked via a hashbang? <lechner>mirai / i think i figured it out. i just did not know enough about hashbangs. i also prefer calling them pound-plings <somenickname>nckx: Did you already check why that "Error in service module" error happens? <somenickname>nckx: Ah you are offline. I am going off as well. See you tomorrow <ted-ious>I don't find many hits when I search for guix and systemd. <ted-ious>I see something called shepherd I've never heard of. <janneke>the shepherd used to be called/known as gnu dmd <ted-ious>Ok then that's something for the homework list for getting started. <ted-ious>Do I also have to learn how to write code in lisp or can a new user just stick to the config files for installing and configuring the system? <lechner>ted-ious / we call it scheme, and it would be hard to install Guix without some exposure to it <ted-ious>Usually my newbie questions are silly. :) <lechner>sometimes, it seems like we are reinventing the wheel, but it truly is a better wheel <janneke>to get started, you probably won't have to be able to understand scheme...but chances are you'll somehow be at least somewhat infected by it :) <janneke>and have been using guix for quite some time, so i'm not really someone who could answer that <ted-ious>I get the impression that guix is like a more reproducable version of gentoo and that it's a really powerful model. <ted-ious>But I'm not a programmer so maybe it's not a good idea for me. <nckx>lechner: If you still care, I bet this is BINPRM_BUF_SIZE in include/uapi/linux/binfmts.h . <nckx>PotentialUser-47: Did you eat it? <PotentialUser-47>nckx noooo, i screamed, went on a walk then put on gloves and chucked it in a bush <nckx>(Apart from the screaming and fleeing your home, +3 drama points for that.) <vagrantc>ted-ious: the amount of scheme you need to know to do useful things is limited. i am proof of that. :) <ted-ious>I found a video with a geek showing off his guix system and talking about scheme and his config files. <vagrantc>well, i would not even say i understand scheme. <PotentialUser-47>the most similar thing i know in python, just learning about quoting and also gexp-s <vagrantc>i can repeat the patterns well enough to make a package definition... <nckx>If someone were to claim to ‘understand’ lisp their commit access would be immediately revoked. <nckx>Insanity is not a defence. <vagrantc>i also know when not to mangle things well over my head. i keep within the sandbox i know. <nckx>That's (seriously) probably the most important quality ☝ <vagrantc>by all means, learn as much about scheme as you want and you will probably be able to do things with more confidence than me ... but i just like to point out it is not an absolute necessity. <vagrantc>i may spend longer on something or come up with slightly weird ways of doing things, but that's why we have people review changes :) <vagrantc>guix also is fairly resistant to breaking it too badly, with the ability to roll back most changes most of the time :) <ted-ious>I mean I guess any system can be rolled back like that but does guix have support for it integrated? <janneke>guix supports semantic roll-backs through its tooling, but as nckx says, not bitbucket-style snapshots <nckx>There's snapshotting built into the package manager & system but it doesn't concern itself with things outside of Guix. <nckx>janneke probably said it better if I were clever enough to know what semantic rollbacks are (I intuitively understand what you mean, though). <ted-ious>So you just need to make sure you don't break the system so much that it doesn't boot. <janneke>nckx: two different perspectives prolly make it more clear even :) <ted-ious>Then the package manager can roll back to a working system. <nckx>ted-ious: As long as you don't break GRUB you can roll back. <nckx>Well, GC all working generations and then break GRUB. :) <janneke>ACTION notes, also to self, that rolling back gets easier when you remove less generations :) <nckx>Yes, resist the urge to clean too well (at least before a reboot). <nckx>The manual has a bit on that. <nckx>It's janky, but it works. <janneke>nckx: what i mean is that guix's "snapshots" have some meaning attached to it, in fact, often the whole provenance <vagrantc>getting into a guix chroot is surprisingly difficult ... but i guess i get why <nckx>Sure, that's what I intuitively got, the ‘content-aware snapshot’. Just wasn't sure if it was a common term. <janneke>as opposed to "these happened to be the bits on this date, dunno if they were right or wrong" <nckx>Well, one that has never booted before is probably tough, true, and the manual assumes it has been booted. <janneke>"or where they might have come from, or how they might be reprocuded..." <avalos>How do I configure `guix shell` to give priority to packages inside the manifest rather than inside my home profile in the PATH? <vagrantc>it has also been a while since i tried and i am probably lsightly more savvy than i was when i last tried <avalos>... the PATH inside the shell environment always has `~/.guix-home/profile/bin` first, so it doesn't want to load my inferiors. <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... <PotentialUser-47>0: Gexps are meant to be written to a file and ( ( run) or ( manipulated by other processes)) <PotentialUser-47>1: Gexps are meant to be ( ( written to a file and run) or ( manipulated by other processes)) <PotentialUser-47>in other words, are they only written to a file when being run, or are they always written to file-s? <nckx>Is there a context to this sentence? <nckx>I'd say 0, because of the ‘other processes’. <nckx>What's the most common way to communicate with ‘other processes’ on unix? Write a file. <nckx>You're not dealing with the in-memory representation of Gexps here. <nckx>(Before we open Pandora's box of worms with ‘are pipes files’.) <nckx>Yeah. Serialisation is the crux. <PotentialUser-47>is there a place where i can find currently serialised gexp-s on the system i am using to talk to you? <nckx>I wish I understood the intent behind that sentence myself. <PotentialUser-47>was trying to connect to the concept by seeing if i can view any serialised gexps on my current system <mirai>PotentialUser-47: if its serialized to a file, simply cat the file <janneke>PotentialUser-47: try, e.g., cat `type -p guix` <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. <old>anybody else as problem with their mcron services for home? <old>It seems that my mcron job does not have access to my HOME binaries .. <rekado>janneke: thanks for noticing that java-rdf.scm is not in local.mk <old>Right the PATH environment for home mcron is: PATH=/run/current-system/profile/bin <rekado>I wonder why that is, because “guix pull” installs a “.go” file for it <old>there's a missing path here to get the guix-home/profile/bin <nckx>old: [Why] can't you use gexps instead? <old>nckx: I use g-exp for my mcron job? <old>but that g-exp must execute external script <old>and it was working very fine for years and now it's broken <old>just weird becuase shepherd has the good PATH set <avalos>Thank you so much, `home-openssh-service` for deleting all my SSH keys and config. <nckx>(My ‘Aha.’ was in response to this being a regression, which I missed.) <avalos>.. wait, it didn't delete my keys, only my config. <nckx>I thought guix home backed up ‘legacy’ (not my term) configuration. <avalenn>files like $HOME/1693917205-guix-home-legacy-configs-backup/ <nckx>~/TIMESTAMP-guix-home-legacy-configs-backup whisper the docs. <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 <lilyp>directory union does use symlinks tho? <lilyp>however, these symlinks are in leaf position, since you have to actually merge e.g. two package's share folders and you can't do that with a symlink alone <nckx>For me, the lack of (at least this) run-time overhead was one of the selling points of Nix/Guix. <janneke>rekado: ah, now that's interesting...