IRC channel logs
2023-01-18.log
back to list of logs
<nckx>gnucode: I would argue for making it a Guix default rather than some build farm quirk. <HexMachina>hmmm, I think the problem is for the signature file it tries to download - some mirrors have the .gz but we are trying to download a tar.sign? And no mirror has the combo of matching archive and signature file? <nckx>Its value is largely in ‘guix build --rounds=2+’ IMO. <ieugen[m]>thanks nckx I did not know that . not an IRC fan <HexMachina>I let it run a bit longer and finally found both the gz and the tar.sign, and then ran into the same signature issue I did with Make <HexMachina>where I didn't have the key used to sign the tarball and gpg failed to download it <nckx>So you think if you add the key and it reaches the lucky server again, it will work? I wonder why so many servers fail; that's not (just) one dodgy mirror being dodgy. <nckx>HexMachina: Something that occurred to me while staring out of the window: does --shuffle print the seed, or can it? IWBN to be able to reproduce from build logs when we suspect make. <ieugen[m]>asking again since my last message was truncated: <ieugen[m]>how can I have development enviornments with up to date openjdk, nodejs, hashicorp terraform, ansible, hashicorp vault, etc ? <ieugen[m]>they are not packaged for guix or they have older versions - not the ones I need <nckx>Either (1) by not using Guix to install these packages, but to install them from source or some other way, or (2) by updating the versions in Guix or (3) packaging the missing ones for Guix. There isn't some (4) cheat code :) There's --with-version/--with-latest, but they are not magic and unlikely to be successful here. Still, it's a fourth option of sorts. <ieugen[m]>thanks nckx . How about packaging the binary build released from upstream? <ieugen[m]>for example I would like to use eclipse temurin build of openjdk <nckx>You could do that! But it's often not as easy as people expect. <nckx>Are you using Guix System? <nckx>Well, you could (ab)use Guix to ‘package’ binaries, and these would (probably) even run on your system because it's a Debian system and not a Guix one. <ieugen[m]>do you know if there is any prior work or effort ? <HexMachina>know if anybody has already tried packaging make 4.4 in guix? <nckx>ieugen[m]: I don't know, but binary ‘packages’ aren't really discussed much since it's not a goal of the Guix project. We don't accept binary packages, so people don't really talk much about them, although they can be made. <nckx>This in contrast to e.g. Nix which is full of ‘packages’ that just download some binary and copy it to /nix/store. Nothing wrong with that, just a different vision. <ieugen[m]>yeah, I understand the views of guix / GNU and I respect that. <nckx>It's not a free software thing. <nckx>There would be nothing FSF-wrong with packaging a binary GIMP. But Guix would never do this. For various reasons. <ieugen[m]>however, from a practical point of view, I need some specific tooling. and if I can't use it with guix I would be forced to use something else. The alternative being to wait for a number of years until the pacakges reach guix <nckx>If you can't help update the packages in Guix, you'll have to use something else. Nothing wrong with that. <ieugen[m]>yes, I know it would not be wrong - but at least some discussion and some options would be nice - for people who need that stuff now. <nckx>I don't understand. Which discussion are you missing? I think I laid out all options, unless I forgot one… <ieugen[m]>I just wanted to point out that the attitude of guix project of ignoring binary packages might not be in it's best interest. I am not saying that guix project should do binaries or host them. just aknowledge the need exists and some tooling / discussion / docs might be in order <ieugen[m]>thank you for your time and information. not trying to start an argument here <podiki[m]1>well you can run binaries in a container with the fhs option...but if you are on a foreign distro maybe I'm missing how guix fits in, because you want to manage all things with that instead I guess? <nckx>I was going to suggest --fhs above if they were on Guix System, but yeah, you might as well use Debian at that point, it's less effort. <podiki[m]1>i.e. you can run the binary on your host directly anyway, and use stuff from guix, with some fiddling I would guess <podiki[m]1>fiddling = things like package paths maybe, or version matching <nckx>ieugen[m]: There was absolutely no wink-wink-nudge or ‘tsk, we don't do/talk about that here!’ intended in my words. Just that Guix contributors, as a self-selected group, don't tend to ‘care’ about binary packages, and that free software projects tend to implement only that. My ‘you'll have to do it yourself or look at different tools’ was meant to be pragmatic, not preachy. <podiki[m]1>but if some of what you want are language ecosystem package managers, then that gets trickier depending on wha tyou want to do i think <nckx>only that = the things the community ‘cares’ about, in absence of extrinsic motivation like cold hard cash. Which, if there is cold hard cash in Guix, please tell me how kthxu. <podiki[m]1>ACTION lines up behind nckx for this hypothetical cash, hot or cold <nckx>It may even be soft and warm I'm not asking questions. <ieugen[m]>hi podiki , right now I use sdkman.io to manage jvm versions, nvm (node version manager) to manage nodejs versions and also linux brew to install different cli apps I need . <ieugen[m]>those tools install binary packages and I have to install the tools as well in the first place. <ieugen[m]>I hope/believe guix can help me drop all those tools and use it to setup that tooling and provide sane, reproducible** developement environments <podiki[m]1>on the node front...we have a node, but it may be old and js on guix generally is rather non-existent for difficult/impossible to bootstrap/build from source reasons I can only repeat (as I don't work in that area) <podiki[m]1>installing cli apps is probably the easiest, we should have a lot and be pretty up to date in general <podiki[m]1>java...I don't know. seeing stuff outdated as you point out is probably a sign it needs more love, love can also be someone helping to test and push it through <ieugen[m]>podiki: I use babashka (clojure interpretor compiled with graalVM) so that will not be easy to package in guix natively IMO <nckx>podiki[m]1: Just in case you missed it, there is an update to 19 that's unmerged for unclear reasons (although I didn't read closely). <podiki[m]1>nckx: ah, thanks. I had a very aborted attempt at it for unknown reasons before but was out of my depth there <podiki[m]1>ieugen: running these ecosystems in a guix container may still be worth something: isolated from your system's packaging, reproducible up to what gets downloaded (e.g. anything you provide the container from guix should be reproducible) <ieugen[m]>podiki: yes, for personal projects I might be able to work with older versions. I am trying to use this at work and I can't tell my team member: You can't use that tool/verssion because it's not in guix <HexMachina>and also, nothing seems to be cached for the --with-latest invocation. If I exit the shell created by `guix shell --with-latest=git git`, and re-run the command, it goes through the whole song-and-dance again <nckx>why does the Guix log look so random. <nckx>Well yes, because ‘latest’ is not cachable. <singpolyma>ieugen[m]: luckily packaging things for guix is often easy :) <nckx>(Yes, I know, in practice you cache latest things all the time, but I bet that's the current reasoning.) <nckx>Choosing a TTL is a cursed assignment. You will introduce confusion, you have to choose how much, it sucks. At least no caching inefficiently always does the right thing. <HexMachina>aha I see what happened... the "latest version" could change, even if it's still CALLED 2.39.1, so it has to go try to download and verify the package. Once it did, though, the actual build results were cached <HexMachina>presumably b/c by the point it got a validated source download it could get a content hash and realize it had already built that source <nckx>Oh yes. It definitely shouldn't build a previously built tarball again. <HexMachina>so, the song-and-dance of trying all the mirrors was repeated, but the build/check stage didn't happen the second time <HexMachina>which seems to be working as intended, outside of it being weird that it has to try so many mirrors <ieugen[m]>singpolyma: thanks. Easy is a relative term. From what I saw in the guix issue tracker (java, nodejs) I am not convinced that's quite the story. I am currently going through Andrew Tropin's youtube videos on guix to learn about the system. It's quite a lot. <HexMachina>related: is there a way to get "guix refresh" to spit the updated package definition to standard out? The "--update" flag doesn't work because I'm not running guix itself from a source build, so --update fails b/c the source definition is not in a writable partition <singpolyma>I've done a lot of nodejs for guix. It's not fully automatable but mostly just grindy/boring not hard usually. Haven't tried Java stuff <nckx>HexMachina: Looking at those attempts, I can't make a sensible story out of it. Fine, the Norwegian mirror is just slow. Then it downloads the tarball from the Belgian mirror. Then it… downloads the signature from Norway. OK, that can work, they should match. But no! Let's try to ask Norway for the tarball again! Still not there. OSUOSL is bankrupt, great. Let's call Belgium AGAIN. Yay, got a second copy of the tarball for a friend. Let's get th <nckx>e signature from Norway… <nckx>It's not just trying mirrors. It playing sick games with them. <nckx>HexMachina: 🥺 Could you report that bug & log as well…? <ieugen[m]>I do believe there is a use case for binary packages, at least on Debian or other distros. <ieugen[m]>For example, eclipse temurin releases could be packaged in a dedicated channel. <ieugen[m]>I am actualy planning to see if this is fesible. I am a totally noob at guix. <ieugen[m]>I do believe that guix can get more users / attention if it can provide people with temporary intermediary options. <HexMachina>nckx: yes! I think this would be a good candidate for my first guix bug submission <HexMachina>Just need to go down the rabbit hole of setting up email in gnus first ;) <ulfvonbelow>as long as you're not using gmail the struggle should eventually end <nckx>ulfvonbelow, HexMachina: lol <HexMachina>I've used GNUS before and actually got to like it (never tried mu4e or notmuch) but that was at a different job where it was saner to use SMTP with my email server <ulfvonbelow>fun fact: the imap code that gnus uses for the imap select method is not the imap code that gnus uses for the imap mail-source. If you try using the imap mail-source with a large inbox, it will actually consistently fail to download because of a timeout issue <nckx>HexMachina: After a minute of musing: Guix could honour the HTTP header cache instructions, if any, for the tarball. It would complicate the code & need to be stored somewhere new, but it would at least make semantic sense. <nckx>Not going to work on it but if you're even bored & want to try getting it accepted, I probably could be persuaded :) <HexMachina>haha there's a lot of stuff I want to do... I've been fascinated by guix for a few years now and casually using it on foreign distro but my scheme chopes are nonexistent <HexMachina>I'd like to learn though! I already live inside Emacs <nckx>ACTION doesn't, so there's hope for us all. <nckx>HexMachina: Thanks for pointing out the CVE, I wouldn't have seen it today otherwise. Now → 😴💤 <sneek>Welcome back the_tubular, you have 1 message! <sneek>the_tubular, lechner says: / good to hear! please file a bug if possible. <nckx>Fine, no account ban for you. <mirai>nckx: even though we're both using the same irc client, I forget that we don't see the same messages <mirai>I've modified this plugin idk where I got from <lechner>i did not see any messages either (only the chanop changes). Why not? <sneek>Welcome back lechner, you have 1 message! <nckx>Me rambling to myself in my sleep isn't the most implausible thing. I am very tired. <mirai>hides left/quit messages if they haven't typed anything for a while <lechner>mirai / that's also what i saw, effectively (in Circe) <nckx>Yeah, I have that set for other channels too, but enough people don't. <nckx>the_tubular: nftables…? I regret to inform you that Libera dot the Chat is not in fact run from an old Dell in my cellar. <nckx>It would be 92% Guix wallops if so. <the_tubular>Btw what happened to Freenode ? Did it go up in flames ? <mirai>whether it went in flames I don't know but what was of interest is no longer there <mirai>so in practice it's the same effect <nckx>the_tubular: It's still there, but it's just trolls & ASCII spam, but mostly silence, now. The real users have all left save for a handful of channels I've been told, but haven't even seen evidence of that. <nckx>Just really low-quality chats, if even any. <nckx>It's been a while since I connected. It was ‘fun’ during the collapse, but you really aren't missing anything now. <nckx>With this unexpected coda, I will now leave you for realz. Good night! <lechner>i think he'll be back within the hour <mirai>pressed y instead of e with send-email <mirai>apteryx: hope v2 was sent correctly <lechner>bot testing: managed to get #60224 in good shape, so long as #60802 is applied first <gnucode>It's a pretty basic way to set up gnus in emacs. Though searching for email in Gnus in my opinion is pretty annoying. <gnucode>lechner: may I ask what you are apologizing for? <lechner>your message got caught up, and possibly lost, in my testing <gnucode>oh no worries. I'll post it again then. <gnucode>HexMachina: You might be interested in setting up gnus this way. It' <HexMachina>gnucode: thanks! For gmail browsing I'll mainly use the web interface, I just want to be able to compose and send email from within emacs <shcv[m]>I tried to set up an emacs-exwm environment using the installer, but ended up with warnings about ambiguous initforms in xcb-ewmh.el; any ideas what I might have messed up? <lechner>maybe xcb is newer. i get occasional errors with exwm from melpa, too <shcv[m]>"Warning (comp): xcb-ewmh.el:171:1: Warning: Ambiguous initform needs quoting: xcb:Atom:UTF8_STRING" <lechner>i think i have a patch pending with an update, but i am not sure <shcv[m]>lechner: ok... what can I do about that? <lechner>actually, i think your issue is the Lisp side <shcv[m]>it seems to be an interaction between native-comp and the xcb lisp code <gnucode>lechner: are you using guile for the guix-helper-bot? <shcv[m]>lechner: not sure; it's not showing up in `guix package -I`; now I'm wondering if my profiles didn't set up correctly <shcv[m]>the version of emacs-exwm in my channels (package --show) is 0.27 <lechner>shcv[m] / that's what i have from melpa. how about xelb? <shcv[m]>read that wrong (tiny font on a 4k laptop) <lechner>maybe yours is only a lisp quoting error. do you have any issues with EXWM? <gnucode>lechner: That is such a short bit of code! wow! <lechner>gnucode / right? rekado recommended it after i played with Limnoria in Python. It was a fresh breeze <gnucode>What lets you talk to irc? Is there some C library dependency that I am missing? I'm kind of in awe that the bot is that small amount of code. <mirai>you could use telnet (or openssl) to talk IRC <shcv[m]>actually, those are all warnings; I'm not sure if they're the problem or not. I don't think exwm is working though, because emacs stays small in the corner instead of going fullscreen like usual after loading exwm <lechner>shcv[m] / did this config ever work? the order is very important <shcv[m]>lechner: no; it's a new install on a new laptop. Originally generated by the installer, but I did edit it some (not the package parts though) <shcv[m]>running 'exwm-init again manually makes it go full-screen, so maybe it's just trapping on the warnings <shcv[m]>ok, sigh it was just a first time thing as a result of the initial compilation warnings. Confusing, but not actually a problem <shcv[m]>lechner: do you use wifi? how do you like to manage it? <shcv[m]>it seems like the kind of thing that should be solved for emacs/exwm, but I haven't found much <lechner>shcv[m] / i do not presently use EXWM on the equipment that connects to wifi. I have a few laptops that currently run Gnome, but i may switch to connman when (and if) i switch to EXWM on those machines. i only use them for video conferencing and some other conveniences <shcv[m]>lechner: ok; why connman specifically? <lechner>shcv[m] / actually, that was not a well-informed answer. some folks suggested it to me to detach from some of the elogin/dbus machinery but i am not sure i actually like it. even worse, i have not researched any other alternatives <mirai>networking service is a rather big yak to shave <lechner>gnucode / thanks for the compliment earlier <apteryx>hmm, 'guix deploy' fails with "error: qemu-binfmt-service-type: unbound variable", without any change in my config. <apteryx>it also looks into /usr/local/etc/guix/signing-key.pub... what <bumble[m]>does anyone have advice for "fixing" this? what does it mean? <cgenie[m]>I have a package where I use `(local-file "some-dir" #:recursive? #t)` to add local directory as a package. I then want to build a Docker container with it, but have some sane symlink to `/code` of my package. I tried `docker pack -m manifest.scm -S /code=my-package` but it doesn't work, how should I proceed? <bumble[m]>@unmatched-paren reconfiguring my system with sway latest did not have any effect btw <civodul>interesting: bordeaux.guix has a substitute for /gnu/store/b6db84pyzrmgzpsrl18ilx8wcmk2ag32-gdcm-3.0.20-checkout <civodul>but if i build it locally, i get a hash mismatch <civodul>cbaines: is there a log of this checkout somewhere? <civodul>i get "actual hash: 1rf0p7dnakjry0fa6ax1h762bn0l5n6ibfdxn077mjvwgpqan51l" <nckx>civodul: Did you delete that store item from bayfront? <sneek>Welcome back nckx, you have 1 message! <civodul>nckx: nope! but it could be that it never made it in the local store <mirai>zcat output is kinda funny when you run out of space: ERROR: In procedure fport_write: No space left on device <mirai>ERROR: ERROR: ERREIOnRR :Rp OrRo:c edure InI fport_writenp r:po rcoecdeudruer e No space left on device <mirai>fport_write: No space left on device <nckx>I think that's how Linus did his first ‘can-Linux-multitask-now’ test. <nckx>(Not with zcat, obviously, but by trying to trash his terminal.) <nckx>civodul: Is it possible for (1) git clone git://…gdcmdata submodule to fail (firewall?) but for git to somehow still return success or (2) Guix to somehow miss that git failure, and continue to hash the source with the submodule missing, returning the non-recursive hash? On bayfront, I mean; it seems obvious that the error in the package definition was a human one. <nckx>What I don't get is how that led to a /gnu/store/<righthash>-gdcm-checkout to hash to <wronghash> contents. <nckx>Without human intervention. <nckx>Good guess, but <wronghash> here is specifically ‘the submodule's missing’, which would be a very (too) neat form of corruption :) <efraim>maybe if there was a patch for gdcm without the submodules and then it was pushed with the correct hash with the submodules. guix-qa would've downloaded the initial one, and both versions would've had (file-name (git-file-name name version)) <efraim>I've run into problems re-finding the hash of git repos where I've added or removed #:recursive? #t, where the <wronghash> is assumed to be correct. <nckx>efraim: I was also suspecting QA. <efraim>seems like the easiest way to get some sources added to bayfront <nckx>Yes, that last thing is something I think we've all encountered: it is plausible for a human to introduce that kind of error, but it shouldn't be for a machine. However, I guess QA turning patches directly into substitutes now changes that? I'm still not sure how, but it's the only route I see. <nckx>I'd would like to roll back that fact if possible :) <nckx>It's great that QA can share (expensive) resources with bordeaux but this is a bit 2 spooky 4 me. <efraim>I'm going with bug in how the hash of a git repo is calculated when #:recursive? #t <nckx>Our patch tracker has no access control, and while this probably couldn't be exploited, I'd rather not rely on my assessment. <efraim>QA building and GCing the source and outputs would be far more expensive than just building them <nckx>I don't mean QA is bad, just that this kind of thing could previously only happen if someone trusted with SSH access was using bayfront to speed up their development. It was very limited in scope. If it can now happen by accident through any old ML post, that's objectively worse. <efraim>I agree, I think it's a great service. We just found a bug that needs to get fixed <nckx>Guix still caught the error, so I'm not worried about security with the big S. But I'm not really *qualified* to not worry, is my worry :o) <efraim>on another note, libxslt won't cross compile on core-updates. If I move python-minimal-wrapper from inputs to native-inputs then suddenly native builds retain a reference to it <efraim>nckx: Makefile fragment: if directory exists, insert BAD THING™. send patch with #:recursive #t, push without #:recursive #t, correct hash later, say oopsies <nckx>Chance of success: low, but eek. <efraim>ACTION is not going to grep the log for hash errors <efraim>libxslt-1.37 needs python-3.10, i'll switch it back to 1.35 locally while I test my llvm-for-mesa patch <efraim>doh, 3.10 is in core-updates. I just had to change it from python-minimal-wrapper to python-minimal <mirai>is guix refresh working for vnstat? <mirai>I'm trying to get it updated but its failing with gpg errors <mirai>it doesn't let me import it (within refresh) <mirai>though I'm not sure if I should do it anyways <nckx>I mean, is it an actual GPG error or just ‘no such key’. <mirai>I'm not too familiar with PGP and importing keys left-and-right doesn't seem like a Good Idea™ <nckx>GPG uses keyserver.ubuntu.com by default and it seems that Teemu's key isn't on there… <nckx>ACTION goes hunting for a 23EF1DD76E65248FB055201ADAFE84E63D140114-shaped duck. <nckx>On importing: that's how it works, you need to import the public key to check the signature. This will not ‘trust’ said key in your daily GPG-ings. Guix points GPG to a Guix-specific keyring. <apteryx>I previously installed a system via ./pre-inst-env which had the erroneous sysconfdir, but I've since pulled and reconfigured, and rebooted, so I'm confused. <apteryx>mirai: the idea is trust on first use (TOFU); the key sticks around in your local keyring and can be reused for future releases, if the project keeps using it <zerobug>is reading 'The Linux Programming Interface' really helpful for guix <nckx>As helpful or unhelpful as on any other (Linux) distro. <mirai>is it normal for tests/pack.scm to randomly fail (make check) <Fd9a>Hi. Has anyone already run Guix on VisionFive 2 RISC-V board? I'm trying to build an image, but a strange error appears - error: wsl2-image-type: unbound variable. I run: guix time-machine -C channels-vf2.scm -- system image --image-type=visionfive2-raw ~/dotfiles/magi/system/kokuou.scm --system=riscv64-linux. For the build I use the wip-riscv branch, where wsl2-image-type is not defined. I don't understand where this error is coming <mirai>sometimes it succeeds at first, other times a second run of make check passes it <mirai>+ #<&store-protocol-error message: "some substitutes for the outputs of derivation `/gnu/store/adbqhbvakzr99g5p41014ny7x60fda9y-module-import-compiled.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source " status: 1>) <mirai>guix substitute: warning: try `--no-substitutes' if the problem persists <mirai>guix substitute: error: connect*: Connection timed out <jpoiret>Fd9a: can you `git clean -df` your check-out of guix in `.cache/guix/checkouts`? <nckx>mirai: It's hard to reproduce these things, but I see no slowness (at all) for that URL. <nckx>Nor random connection failures. <nckx>ACTION gets some other test failures, tests/build-emacs-utils.scm & tests/build-utils.scm, but did not look into them. <apteryx>mirai: random test failures are not normal, no <Fd9a>jpoiret: I'll try to clear the cache <efraim>Fd9a: IIRC everything from the wip-riscv branch has been merged into master <efraim>I haven't tried building an image for the visionfive2 yet, my board hasn't arrived yet <Fd9a>efraim: I tried to build with the master branch, but there was an error when building guile-2.0 or 2.2. I need to check again <nckx>ACTION finished with 9 ‘make check’ failures, wowee. <nckx>#<&store-protocol-error message: "setting journal mode: database is locked" status: 1>) <nckx>Yes, Guix, this is not a dedicated test suite machine :-/ <nckx>ACTION throws another penny into the ‘rewrite guix-daemon’ bounty jam jar. <nckx>That's like 5 pennies now, folks, what's holding you back. <efraim>OK, I got glxgears running on core-updates using my new llvm-for-mesa package <efraim>also cross compiling mesa on core-updates is broken <mirai>uh, what is the make target for service tests? <nckx>Optionally, TESTS="run-these tests-only". <apteryx>rekado: odd, I do not have emacs-geiser-guile explicitly installed <apteryx>it it propagated by emacs-guix or something? <nckx>Fd9a: You'll have to set up risv emulation through the qemu-binfmt-service-type to ‘natively’ build for that system type. <nckx>Fd9a: (lookup-qemu-platforms "riscv64" […]) to be exact. <mirai>is it possible to have more than one store? (not /gnu/store) <apteryx>strange; my %sysconfdir == /usr/local/etc problem originates from /gnu/store/kpzwj8lkv91whf25cgh17kpch5j1fw93-guix-module-union/share/guile/site/3.0/guix/config.scm <nckx>You could configure & build multiple guixes with different localstatedir/storedirs/etc. and be extremely cautious the entire time you're using them, and you might just get lucky and it might just work, but I think ‘nope’ is a better rounding down of all that. <mirai>:( pity, I was thinking an alternate store could be used for making custom flavours of "non-packages" <civodul>custom flavors of non-packages, interesting :-) <mirai>think of video editing or file sharing <civodul>you could still use the same store, but maybe you're afraid it might become too big? <mirai>you could intern the original files in a store and spin up your own "modified" file <apteryx>which is referred by /gnu/store/xvpk83hgyx1bm5pdkash8py4pnfqhxqc-guix-51f8a7ace, which must have been a development guix from my tree at some point <mirai>for things like packages and source code /gnu/store tends to be alright on your usual systems <apteryx>tracking the referrers further it seems it gets pulled by /gnu/store/hpy3j8fj2w0qv95q1f5vql37wwhnwlbd-inferior-script.scm <mirai>but very big binary objects will be... tough <apteryx>I only have one inferior defined, and it pegs Guix at commit 9ed65e6af77893b658a7159b091b5002892c2f95, not 51f8a7ace, so I'm confused. <cbaines>civodul, nckx, I'm just reading your messages about the /gnu/store/b6db84pyzrmgzpsrl18ilx8wcmk2ag32-gdcm-3.0.20-checkout substitute <cbaines>I'm not quite sure what the problem is, it's perfectly possible that the git repository has changed since that derivation was built <nckx>cbaines: If you have the time, could you walk me through how that would cause this, specifically (not just ‘tagged git hashes can change’)? <nckx>I assumed you meant the upstream repository too. <cbaines>nckx, I don't know specifically, but in general, fixed output derivations might build one minute, then not the next <nckx>I guess they could have added the submodule after the release? I'm not solid on how they work. <nckx>Sure, but the general case is a bit too general here. We know the network can return anything, but why would it specifically return a missing submodule. <nckx>And why would git not detect that. <bjc>submodule commits are linked to the parent repo's commit, so you can't change them after the fact <nckx>Unless, of course, it was added later by upstream. That's possible! I'll check their log. <cbaines>that I do not know, I haven't used submodules in quite a while <bjc>a submodule just consists of a pair (git-uri . commit) in a .gitmodules file, which is committed as normal <cbaines>nckx, on the bayfront local store topic, this and other built outputs don't pass through it. That was a big point of the Guix Build Coordinator design, it's not limited by how much it data it can move through the store (and thus should be easier and more efficient to operate) <bjc>not sure what the specific problem is, but if you're working off a tag, rather than a commit sha, and it got retagged and force pushed, that could cause problems <nckx>Oh but it's not locked to any commit. I find that surprising, but again, submodule noob. <bjc>i *think* the .gitmodules file only ever contains commit ids, with the possible exception of someone manually editing it <telmo[m]>Gostaria de algo do género, mas para o sistema guix <nckx>cbaines: Ah, so it was only ever on a build node and subject to GC at any time? Also, interesting; is there a design/background document about this store bottleneck somewhere? <nckx>I checked your blog but maybe that's the wrong place :) <nckx>telmo[m]: Are both windows from Distrobox? So it has a certain level of insight into Nix attributes? That is nice. <nckx>Wrong place indeed. Thanks. <cbaines>while I think the problems with ci.guix.gnu.org having lots of items in it's store have been mitigated by having the store on an enormous storage device, I'd expect them to return as that device fills up. Or at least for this to return to being a limiting factor to the rate at which things can be built <bjc>out of curiosity, how much space does the store take up on ci? <cbaines>maybe improving the guix-daemon to allow for non-blocking GC would help with this, but even then, I still think there's an efficiency argument to be made for not storing things multiple times (in the store and cached nars) and not generating and unpacking nars multiple times <apteryx>a bit less than 10 TiB currently I'd say <apteryx>the bulk of the storage space is consumed by the package archives (NARs) ready to be served (> 22 TiB) <apteryx>cbaines: why are nars generated and unpacked multiple times? <nckx>cbaines: Does bayfront try to use its own nars first when building something with missing inputs? <nckx>own == ‘cached’, but equivalent to --substitute-urls=me :) <apteryx>the store on ci is not precious, could be wiped anytime <cbaines>apteryx, as I understand it, a store item built by Cuirass goes through this process: store (on build machine), nar generated by guix publish on build machine, store on berlin, nar generated by guix publish on berlin <cbaines>apteryx, this is slightly simplified, but the nar is generated twice, plus you end up with the output in the berlin store <cbaines>apteryx, in constrast to the build coordinator on bordeaux: store (on build machine), nar generated by the agent, nar copied to bayfront, nar injested by the nar-herder <nckx>Even if you're directly copying, Guix uses ssh compression by default IIRC, making it equivalent (or worse than zstd nars, depending on how you're counting). <nckx>Is injested a deliberate pun? <telmo[m]><nckx> "telmo: Are both windows from..." <- no, replace guix for nixos iso fork <telmo[m]>speak snowflakeOS and it is the remaster <nckx>(cbaines: ‘Injected’ [indicating a certain level of disregard for ‘proper’ layering] + ‘ingested’. Just wondering.) <cbaines>nckx, haha, no, I'm just bad at spelling <telmo[m]><nckx> "telmo: Are both windows from..." <- but i switch at the momment why distrobox not is now in official repositories <nckx>But there is no right-window equivalent for Guix. <cbaines>nckx, as for your earlier question, I'm not sure I get what you're asking? bayfront uses bordeaux.guix.gnu.org substitutes, as do the build agents. <cbaines>nckx, also, the build coordinator is very particular about being able to substitute build inputs, it'll never start a build until all the inputs are present. If it fails to substitute them, it'll report an error to the coordinator <apteryx>is deploy broken for everyone at the moment? it seems to be throwing random 'unbound variables' at me. <rekado>just to correct any misunderstandings: on ci.guix.gnu.org the store sits on a huge storage device, yes, but we’re using the big storage for cached nars, not as a way to keep the store growing. <cbaines>(in the future, I'd like to maybe make this more rigorous, so that the hashes of the inputs are checked <nckx>cbaines: <bayfront uses bordeaux> OK, that was all I meant. Whether ‘bayfront’ would unpack its own cached nars from ‘bordeaux’ directly. Which would be obvious, but I didn't want to assume :) <nckx>With zstd and server-tier I/O, that's beyond cheap anyway. <mirai>if I develop a patch for a package that triggers 1000+ rebuilds, do I need to rebase to core-updates/staging or do I just put core-updates/staging in the subject header? <cbaines>nckx, on that point, the bordeaux substitutes are all lzip'ed. I recently finished the first attempt of introducing caching nars with different compressions though, so I'm hoping that zstd nars can become more of a thing soon <cbaines>rekado, I'm not sure if there's any data on how fast the berlin store is growing, but from the configuration, it'll only start GC'ing when the 100TiB storage are is 85% full. Assuming that the store is 10TiB currently, and it continues to take up a third of the used space, that would mean that the store would be ~28TiB when the first GC happens. <mirai>I'm getting thrown off by this ganeti comment <apteryx>seems my deploy problem is related to the 'virtualization' module <mirai>does gnu/tests/ganeti.scm want 127.0.0.1 localhost in the /etc/hosts file or not? <cbaines>I guess to me, a 10TiB store seems excessively large, I don't know why so much data would be needed in the store. <apteryx>does using C-c C-k to build the module with Geiser result in 'mkstemp: Permission denied' for you too? <nckx>cbaines: Yes. If no substitutes are being served from it, that is an excessive amount of history to keep live. <apteryx>cbaines: I haven't reviewed the 'guix gc' scheme, it could probably be made more aggresive <apteryx>I think it might not even trigger at the moment <cbaines>that's my reading of the configuration <nckx>Even 1 TiB is extremely a lot at current package/source sizes. <apteryx>should we start a manual 'guix gc' and time it on berlin? for benchmarking <cbaines>even if GC'ing was happening though, then it comes to at what point the throughput (the rate of building things) becomes limited because you're blocked when you're GC'ing <mirai>civodul: is there any trouble if we move hosts-service-type to %base-services? (it's currently part of operating-system-default-essential-services) <cbaines>which seems unnecessary to me, since it's perfectly possible to just not force everything that's built in to a single store <nckx>Has anyone timed a GC on the SAN yet? <nckx>ACTION remembers the old multi-day ones, shudders. <telmo[m]><nckx> "But there is no right-window..." <- gtk application for use guix package without use terminal <telmo[m]>for noobs its is good idea for the freedom <apteryx>from /var/log/mcron.log: 2023-01-18 16:00:00 123274 /gnu/store/6bp35nxrvbdccmr278zadglwq4jzrpdg-guix-1.4.0/bin/guix gc -F8246337208320: guix gc: already 74173416.18359 MiBs available on /gnu/store, nothing to do <apteryx>so it'd trigger only when less than 74 GiB is left? that's bad <cbaines>I think it's 15TiB from the configuration <cbaines>I think that log line corresponds to the config that does a GC at half that configured threshold (7.5TiB) <apteryx>cbaines: I think the guix gc job configuration for berlin is from frontend-services, configured via its gc-threshold, which defaults to 800 GiB <apteryx>it's explicitly set to 15 TiB in berlin.scm <apteryx>so it'd wait to fill up 85% of the storage before doing anything <cbaines>yep, which with so much storage is a while off at least <apteryx>I think we should run a full 'guix gc' daily or weekly instead, if our intent is to keep the store small <cbaines>so there's no need to worry about GC blocking stuff in the short term <apteryx>but we do not want to have a 65 TiB store to gc, as even with fast storage that'd be pathologic <pret7>heya :D, why does guix still use gcc 10 for a lot of stuff? I'm working on a package for node 18 and just wondering <pret7>op lol there's an open patch for it <nckx>Because replacing the default GCC used for almost $everything involves rebuilding almost $everything (strictly: more), so these upgrades are performed on the core-updates branch. <ecbrown>the french historically have had a love affair with the number 10 <nckx>You can (almost) always use a newer GCC version ad hoc for specific packages that need it. <pret7>because there's this annoyance <nckx>apteryx: Do you know how GC scales? Linearly? Murderously? <nckx>pret7: A naive (and possibly wrong) answer would be: node-gyp should not be using the ‘system’ compiler in the first place, instead it should be made to invoke the GCC used to build the rest of Node in Guix. <pret7>yea I wonder if there's a way to configure that... <apteryx>nckx: I'd assume it's linear, on a competent file system <nckx>You'd modify the node-gyp package to replace the equivalent of ‘execvp("gcc")’ with the actual full file name of GCC, at build time. <nckx>No idea how/if that works in JS, but it surely must. <nckx>Guix will then make sure that <exact full file name of GCC> is always available when node-gyp is around. <nckx>That means that node-gyp will always pull in GCC, but that seems reasonable here. <nckx>Certainly more reasonable than the status quo. <nckx>apteryx: Nice disclaimer (not that I disagree…). <civodul>mirai: i think it has to be in 'essential-services' so it can put the actual host name as an alias in /etc/hosts, as is currently the case, no? <mirai>right now it's part of the (operating-system-default-essential-services os) procedure <mirai>but this makes it impossible to override its initial value? <mirai>gnu/tests/ganeti.scm for instance doesn't want its own hostname as an alias of localhost <mirai>but moving hosts-service-type to base-services = how do we fetch the hostname to use it as alias? <civodul>'essential-services' *can* be overridden, it's just something rather unusual <civodul>so i would keep it in 'essential-services' <mirai>unless we put the hostname in its own hosts line <mirai>not as an alias of localhost <mirai>is there a way to retrieve the hostname from within base-services? <civodul>each service only sees its own config value <mirai>hmm... so we can't have hostname as an alias of localhost then (not in essential-services) <mirai>wait, nvm, that's the issue in first place <mirai>there's no way to get host-name from base-services <mirai>I've no idea how we can move hosts-service out from essential-services <podiki[m]1>does anyone have a sample elogind-service definition? I inherited config and included a (handle-power-key ignore) but it didn't seem to do anything (still powered off on power key) <podiki[m]1>oh, is it 'ignore actually? (didn't get any error in reconfigure though) <elais[m]>Hello guix! Long time no chat. I was wondering does anyone know how to get around the problem of the sd card for an arm card losing the bootloader after a reconfigure? <nckx>podiki[m]1: Symbols, yes. What did you use? <podiki[m]1>literally just ignore (I had a single quote to start by pure muscle memory but then saw fields in the doc explicitly do e.g. ("disk") so I thought for some reason the doc was being exact in not putting a quote <podiki[m]1>but no error seems odd, would expect some undefined symbol or something <nckx>Are you sure it was evaluated? <nckx>If I s/'ignore/ignore/ in my system configuration I get the obvious and expected ‘error: ignore: unbound variable’. <podiki[m]1>(elogind-service config => (elogind-configuration (inherit config) (handle-power-key 'ignore))) <nckx>That looks correct… and there's an elogind-service in the first argument to modify-services for it to modify? <podiki[m]1>and then i'm confused when something is service-type or just service....is that it? <nckx>elogind is -service-type. <podiki[m]1>it is part of a modify-services %desktop-services form <nckx>There might be a -service legacy variable. <podiki[m]1>was that the difference with -service and -service-type? one is older style and has been (mostly) replaced? <podiki[m]1>ah yes, that does it, with -service-type it gives error on "ignore: unbound variable" <nckx>And service-types are actual, well, types; the -service constructors are procedures that in theory can do anything. <nckx>Poor failure mode, but at problem at least solved. <podiki[m]1>so is it just a typo in the manual (only elogind-service)? or is there an elogind-service that should still be mentioned <nckx>podiki[m]1: So the single ‘(service <TYPE> [<CONFIGURATION>])’ constructor replaces each ad hoc ‘(TYPE-service [literally whatever the author decided to accept])’ constructors. <nckx>podiki[m]1: It is neither. <nckx>elogind-service still exists, but that doesn't mean it's something you can pass to modify-services. <podiki[m]1>one sec, rebooting (a certain kitten has the uncanny ability to press certain buttons) <nckx>The manual could and should be updated to use elogind-service-type everywhere, so we can eventually deprecate elogind-service, but strictly speaking there are no typoes. <podiki[m]1>I see; I had noticed that all my other modify-services were -service-types and was thus confused in manual <podiki[m]1>I would have to look to see where type is mentioned and where it is just service <nckx>podiki[m]1: Maybe it helps to understand that there are no ‘two elogind services’, never were; just two ways of returning that service. You can imagine a compatibility (define* (elogind-service #:optional (config (elogind-configuration))) (service elogind-service-type config))) if you like. It might even be; I didn't bother checking because it doesn't matter. <nckx>The body of that imaginary procedure above is the new style which you might as well start using. <podiki[m]1>if we don't already have a little thing explaining the difference? <elais[m]>elogind-service outputs elogind-service-type, correct? <podiki[m]1>right, one actual service, some syntax which is a different form of constructing it <podiki[m]1>well, my elogind change did something...it broke lightdm <podiki[m]1>apteryx: glad to have lightdm back, but my change to elogind to ignore power key seems to have broke it (just get blinking cursor) <apteryx>podiki[m]1: does the lightdm system test reproduces the problem? <podiki[m]1>I have not tried to run the tests, I'm justusing lightdm (no configuration change) which worked, modifying elogind to change power button behavior gives me just the blinking cursor <mirai>civodul: I've sent a revised v2 patch series but patch 2/3 still needs to be addressed <mirai>incorporates feedback from the first series <podiki[m]1>apteryx: haven't run yet, but looking at the lightdm tests, it just looks for empty greeters or multiple configurations; I haven't modified either <apteryx>perhaps worth trying them, the tests provide a VM to test things there too <podiki[m]1>ok will do. in the meantime, any hints on what might be going on? <podiki[m]1>or is it unrelated to lightdm and is the elogind change? (I'll try with another dm) <apteryx>I'm not sure, but it could be a lightdm bug <apteryx>any errors under /var/log/lightdm/ ? <podiki[m]1>a belated thanks for lightdm service though, i used to use it on arch and have preferred it over sddm/gdm <apteryx>glad to know it has at least one user ;-) <podiki[m]1>ah, error in seat0-greeter.log: Error reading existing Xauthority: Failed to open file ?/var/lib/lightdm/.Xauthority?: Permission denied <katco>podiki: ah foo. i knew i'd miss something. <sneek>Welcome back katco, you have 1 message! <podiki[m]1>katco: looks like nckx did some merging but I'm not sure if that got everything <podiki[m]1>(I would have done it but twas late when I saw it) <katco>oh. i just issued a merge command too =| <podiki[m]1>should be fine? the message I saw was only a few bug numbers, not the full set <katco>so i'm supposed to send the first patch in, wait for a bug number, and then submit the rest against that bug number? <nckx>podiki[m]1: <not the full set> WDYM? I thought there were only ~25. (‘Only’, urgh.) <nckx>The manual should have a dot to say about that somewhere in the Contributing section. <podiki[m]1>nckx: the message I saw (on mumi) had only 3 bug numbers but maybe I missed something <katco>i'm sure it does. it's a lot to keep track of if this isn't something you do day in and day out. <apteryx>podiki[m]1: what happened there? did you touch your $HOME permissions? <podiki[m]1>nckx: ah, I think it was a delay on the frontend, I only saw your second message <podiki[m]1>apteryx: no changes to my system config besides sddm to lightdm and elogind power button <katco>nckx: thanks for doing that. sorry for the noise :( <nckx>katco: I'm not sure your message would have worked, debbugs doesn't like lines that are that long (maybe 72 characters, maybe some other arbitrary limit) IME. <apteryx>ah, berlin needs to build both guix 1.4 and 1.3 because of #55441 <katco>the response i got back seemed to have been correct. i wasn't sure what to do because it said each command should be on 1 line <katco>i wasn't sure if it would drop IDs on subsequent lines or something <podiki[m]1>apteryx: some state leftover from previous dm? but I did use lightdm successfully just before fixing my elogind change <katco>nckx: is 25 patches too many for 1 series? should i have structured this differently? <nckx>katco: No, 25 is fine if they are all related. <nckx>(And even then it gave me a suspicious ‘error’ that it shouldn't have.) <podiki[m]1>apteryx: hmm. i haven't used the vm tests before, I ran the lightdm tests (passed) so it was built, how can I use it now? <nckx>That's the one podiki[m]1 saw. <nckx>Yes. Shrug. ‘Debbugs, am I right.’ <katco>fwiw the one i sent all on one line seemed to work fine <apteryx>podiki[m]1: something like 'guix system vm -e '(@@ (gnu tests lightdm) %lightdm-os)' <apteryx>you can customize its definition if you want to add something <nckx>katco: Did you just randomise the order for fun or profit? <katco>nckx: the order of the package changes? <nckx>I just hope you didn't actually type out each one for 0/25, 1/25, 2/25… <nckx>Which the (lack of) ordering kind of implies. <podiki[m]1>apteryx: neat. it spit out a store path for a script that starts the vm <katco>nckx: oh, no, those were automatically generated. i sent all the patches to `guix-patches@gnu.org` using `git send-email` <nckx>The script even takes extra QEMU arguments if you need them. <apteryx>vagrantc: did you have a chance to look at v5 in #60224? to my eyes, it looks good to go now <apteryx>well, after u-boot-malta is removed per #60802 <vagrantc>apteryx: i keep postponing it, but i've glanced at it <sneek>vagrantc, you have 2 messages! <sneek>vagrantc, civodul says: there's a new Guile-Avahi 0.4.1 release, with build system improvements :-) <sneek>vagrantc, apteryx says: hi! I managed to get #60224 in good shape, so long as #60802 is applied first. Thanks for the comments so far! <nckx>podiki[m]1: Those patch series instructions aren't new, this has always been a necessary ritual. <podiki[m]1>nckx: oh. thought there were some updates/tips on git-send-mail recently <nckx>Yes, but not on that point. <nckx>katco: I meant the ‘merge …’ bug numbers. <vagrantc>apteryx: i had meant to try building some things and whatnot and seeing if they actually boot some of these systems after a significant refactor :) <nckx>podiki[m]1: The apologetic ‘unfortunate flaw’ wording is new though. <vagrantc>apteryx: although, if they get the same checksums on the individual binaries, well, it's obviously no worse than it was :) <apteryx>right, that'd be an interesting check to make <katco>nckx: oh, i'm sorry. i copied them from my email client. it looks like the messages were out of order there, which is why the bug numbers are out of order. <vagrantc>something small could easily change the results, though ... but if they're the same... :) <katco>nckx: does that matter? i thought it probably only mattered that the 1st one was correct <mirai>any idea why docbook-xml-5 is inherited by docbook-xml (4.5) and not the other way around? <nckx>katco: No, it does not matter, it just made me fear you'd done this all manually. <katco>ah, thanks for the concern. if you have any advice/tips, i'm all ears! <nckx>Uhm, TBH I literally just used seq | fold (after checking the range matched the number of patches, and it did, so I didn't have to snip out any rogue numbers in between) to generate the mail. Nothing fancy. Sorry. <nckx>mirai: Why would it be the other way around? <mirai>intuitively, docbook-xml-5 would be a special case of docbook-xml <katco>like a true emacser, i did copy-rectangle-as-kill, then string joined them all :p <nckx>And there's the rub: your intuition is valid, but yours. Somebody else thought the opposite (I personally agree). <podiki[m]1>apteryx: my simplistic change to the vm os config to use elogind with a power-key configuration did not break it <nckx>I like having the latest version stand on its own, and the aging husks to be mere reflections of it. <podiki[m]1>apteryx: I feel like it must be some state on my machine from switching dm, but I'm not sure where to look <mirai>I was planning on using the inheritance to apply this phase to docbook-xml packages <mirai>the phase reads the package version and patches accordingly <mirai>but for some reason, only version 5.0.1 should be patched as 5.0 <mirai>otherwise, 4.4 -> 4.4, 4.1.2 -> 4.1.2 <mirai>so the 'base-package' that is docbook-xml-5 will need a specific phase <nckx>I don't really get the ‘otherwise’ clause above. <nckx>I also missed the ‘this phase’ if posted above. <nckx>But I also need to leave a bit. <mirai>what I want to do: only docbook-xml-5 (which has version 5.0.1) should be patched in some phase as 5.0 (major+minor) <mirai>all other docbook-xml packages should use the full version <vagrantc>apteryx: i wonder if you couldn't decouple the removal of u-boot-malta from the other changes and just ... remove it? :) <podiki[m]1>apteryx: any idea why lightdm is trying to load xauthority from /var/lib/lightdm and getting a permission denied? <podiki[m]1>apteryx: I do see an .Xauthority there, owned by 980:974 (directory .cache and .dbus owned by same 980 user group 974) <apteryx>vagrantc: it's already decoupled, and nobody commented on it yet, so I guess I could do that already (it's trivial enough) <vagrantc>apteryx: well, i mean, it seems like a 2/2 patch on an otherwise unrelated series <apteryx>it's related in that to reproduce 1/2 you need u-boot-malta to still be there <apteryx>*reproduce the problem solved by 1/2 <vagrantc>last time i updated u-boot i seriously pondered just removing it <old>I've just discovered that my CI was not building package variants correctly for weeks now. I had a option transformer with no effect <old>Is there a way to make `guix-build' fails if an option transformer has no effect? <apteryx>nckx, rekado, cbaines I just sent a suggested change to berlin to run a full gc daily <neox>Is GTK4 supported with python under Guix System ? <neox>I installed the following packages : gtk, gobject-introspection, libadwaita, python, python-pygobject <podiki[m]1>apteryx: lightdm doesn't work anymore even without the elogind config; something funky going on, why is /var/lib/lightdm owned by 972:974?? <neox>I encounter a fatal error : "TypeError: gobject `gemgraph+main+Application' doesn't support property `application_id'" <podiki[m]1>apteryx: fixed! i removed /var/lib/lightdm (and lightdm-data) and reconfigured. somehow the directories were owned by that weird numerical user not lightdm <podiki[m]1>apteryx: maybe my bad elogind config syntax messed something up...? seems weird though since it did work at first. i'll blame state <apteryx>podiki[m]1: state I think! we've had that problems with gdm too <apteryx>now it has its /var/lib/gdm on a tmpfs to cope with that <podiki[m]1>ACTION (in best "khaaaan!" impression) staaaaaate! <apteryx>perhaps you switched your graphical login manager to something else, leading to the lightdm user being removed, then recreated when you added it back with a different id? <podiki[m]1>not sure. I think the original operation was changing sddm to lightdm but with wrong elogind config (shouldn't have done anything) which worked, then fixing elogind and lightdm was broken <podiki[m]1>but maybe some ending session then rebooting or something else caused an issue? i don't know. maybe i'll fool around in the vm later (now that you showed it to me, thanks! and I enabled kvm in bios) <cgenie[m]>hello, I try to write a package that will add a single `.sh` script. I'm using `(source (local-file "script.sh"))`, however for some reason it is not executable when I do `guix shell -L . mypackage` <dthompson>anyone else having guile-ssh issues with 'guix deploy' lately? <cgenie[m]>I had to modify `#:phases` so that when I use `gnu-build-system` I delete `'configure 'build 'check` and modify `'install` so that it uses `(install-file "myscript.sh" (string-append (assoc-ref outputs "out") "bin")))` <cgenie[m]>ah ok nvm i guess i need to `(chmod (string-append out "/myscript.sh") #0x755)` <podiki[m]1>if it is just a script to copy, copy-build-system might be less modifications <podiki[m]1>and yes, sometimes do need to do a chmod (not sure when, probably depends on source and what build system may do) <podiki[m]1>and/or look for examples in gnu/packages as some simple packages will use it <podiki[m]1>sounds like you accomplished the same thing basically, but just letting you know there is this option if all you really need to do is copy files <davidl>I was trying to build a thing from source using meson and ninja, that depends on xkbcommon, so I did guix shell libxkbcommon ... ; meson build, but then I get error that dependency "xkbcommon" not found. Is libxkbcommon different than xkbcommon, or what could be the cause? Trying to build: https://github.com/any1/wayvnc. full guix shell command was: guix shell --check gcc-toolchain meson libdrm libxkbcommon wlroots jansson linux-pam gnutls <apteryx>rekado: oh wow, the same happens in ielm (M-x ielm) <apteryx>so it's just an Emacs problem at this point <podiki[m]1>this is with geiser? i've been meaning to use it more, what's not working? <apteryx>it's not just geiser, it's also ielm (elisp repl -- M-x ielm) <apteryx>so there's some bug that got introduced in the last month or so <podiki[m]1>ielm seems to work fine here (never tried it before), though mostly I manage my emacs packages from use-package <apteryx>the problem is that evaluating something doesn't return the prompt <podiki[m]1>i've also cleared out package quickstart stuff when I've had weird errors (like one where geiser would block emacs from starting) <podiki[m]1>~/.emacs.d/package-quickstart (maybe just the compiled one .elc) for me; not sure why, some caching that went awry? <apteryx>moving ~/.emacs.d out of the way didn't help (I still use ~/.emacs.el) <podiki[m]1>nothing helpful in the messages or warnings buffer I take it? or enabling the debugger? <cgenie[m]>with guix pack -f docker -m manifest.scm I can create Docker images from a manifest file. Is there a way to assign this image a name other than some random bash-coreutils-...? <podiki[m]1>speaking of emacs, back to checking out org-present having given up on the fancy js html slides for now <lechner>Hi, can the guile-build-system package an executable? <cgenie[m]>ah i see this is just fresh as `(manifest->friendly-name` :) <apteryx>rekado, podiki[m]1 apparently it's a regression introduced with paredit 26 <apteryx>"NOTE: The Electric Indent Mode workaround turns out to break ielm and other interactive modes, because paredit now defines RET, overriding the binding in interactive modes that submits an input." <apteryx>and then mentions (define-key paredit-mode-map (kbd "RET") nil) and (define-key paredit-mode-map (kbd "C-j") 'paredit-newline) as a workaround, or disabling electric-indent-mode <gnucode>apteryx: does paredit provide an electric-indent type feature? <apteryx>I'll try just commenting out (electric-pair-mode) <apteryx>I do not have other electric-mode configurations, so I'm not sure I understand what that electric mode workaround is about <johnabs[m]>Hi all, I hope everyone is doing well :) I just have one (hopefully simple) question: I want to update my hosts file through config.scm; however, there are a lot of entries in the file I want to use. The documentation isn't particularly clear, but is there a way to load a file into the file-like-object required for the (hosts-file) parameter within the (operating-system) in config.scm? <elais[m]>I believe local-file can be imported through (guix gexp) <johnabs[m]>AH, gotcha. The constructions I found were using plain-file and string-append. To use (guix gexp) do I load that in the (use-modules) section? <dthompson>ACTION found a workaround for bizarre 'guix deploy' crashes... writes to list <elais[m]>that plus the arm openbios bug ruined my weekend <rekado>apteryx: ah yes, I also found paredit no longer working with M-: <gnucode>johnabs[m]: do you want to look at an example config for a hosts file? <apteryx>an inferior's guix seems to be wrong; how can I invalidate the inferior's cache? <apteryx>wrong in the sense it appears to be made from a local git checkout, and has %sysconfdir set to /usr/local/etc instead of /etc <civodul>apteryx: do you have a REPL session you could paste or a script to illustrate the problem? <bdju>does anyone have experience dealing with things that need PlatformIO for VSCode on guix? I see we do not have vscodium packaged. I need something like this to build some [free] software I found for a microcontroller, sadly. <apteryx>by various calls of 'guix gc --referrers', I end up finding a profile containing an inferior script <apteryx>I must have run './pre-inst-env guix pull' once using a git checkout made guix, and the guix cached/referenced by the inferior contains the wrong %sysconfdir? <apteryx>I've since ran 'guix pull' to get a 'correct' guix, but the problem persists <civodul>apteryx: ah yes, that's because things like %sysconfdir are "inherited" from the Guix used to run 'guix pull' <civodul>so yeah, "./pre-inst-env guix pull" gives you a guix that has /usr/local if you chose that as --prefix <HexMachina>is there a way to get "guix archive --recursive --export" to include derivations? I'm trying to use archive to copy some stuff to an offline machine (no internet), and after importing the archive offline, I still can't really use the package b/c it still tries to download source to calculate the derivation <vagrantc>hrm. too many pypdf builds ... https://pypi.org/search/?q=pypdf there appear to by pypdf, pypdf2, pypdf3 and pypdf4 guix has python-pypdf2 1.26 and python-pypdf3 1.0 ... there is also, entirely unconfusingly pypi pypdf 3.2 <vagrantc>there were some changes to diffoscope to support pypdf 3 ... but which pypdf 3? eesh. <vagrantc>those changes also appear to have broken the use of pypdf2 ... and strangely, even though i can't figure out how, python-pypdf3 in guix ... fixes the test suite failures. but does not provide any of the python modules actually used. <vagrantc>also, would anyone be able to help increase the verbosity of the test suite building diffoscope on guix? on builds of the debian package, it manages to list each individual test, but in guix, it only prints a . (success) or E (error) or F (fail) or s (skip) for each test ... <vagrantc>huh. dropping guix's python-pypdf2 fixes the test suite failure that tries to use pypdf2 <vagrantc>as in, the tests using pypdf2 fail when it is installed, but succeed (e.g. not skipped) when it is not installed. <vagrantc>ACTION senses a facepalm in the not-too-distant future 