IRC channel logs
2023-10-09.log
back to list of logs
<afm-guix>Per a suggestion, I have guix running on Fedora (foreign distro). The manual strongly recommends the installation of nscd but this package is no longer available on Fedora. Will this cause problems? Are there any solutions? I did read on the topic and messages that were exchanged at the time of deprecation don't provide a clear path forward. So far <afm-guix>I installed it via a package on Fedora COPR but my dnf fu is small and don't have the skills to extract the pre- and post-install scripts. <psyclimb>has there been any consideration for printing a nice hard copy guix manual? i would love to have one.. <arst>guix archive --export --recursive hello > hello.nar <arst>guix archive --import --authorize < hello.nar <arst>This gives me an error. Am I doing this wrong or is this an actual bug? I submitted this as a bug through email and nothing's been done. <parnikkapore>Hi Guix! I have a cuirass remote-worker running in a QEMU VM, and it looks like it's only using 1 core despite the machine having multiple cores? <sneek>parnikkapore, you have 1 message! <sneek>parnikkapore, janneke says: if it's about 30days, you could postpone deletion to two months by running guix gc -d 2m, for example <parnikkapore>sneek: botsnack! (on that: I talked on another nick; best way is probably to maintain my own gc root list via psql) <janneke>parnikkapore: yes, a gc root is probably the way to go <fnat>How does one deal with multi-line shebangs? It looks like the patch-shebang phases will handle, say, `#!/bin/sh' but how about a possible second like along the lines of `exec guile -e ...'? <fnat>I don't think `guile' gets substituted here, although I may be wrong? <rekado>fnat: it won’t be substituted, because it’s not part of the shebang line <fnat>rekado: Right, got it. So I suppose I can patch it manually when I package it. <parnikkapore_xm>Hi Guix! I have a cuirass remote-worker running in a QEMU VM, and it looks like it's only using 1 core despite the machine having multiple cores? <rekado>parnikkapore_xm: it uses (current-processor-count) to get the number of available cores. Can you check that this returns the correct number in a Guile process? <parnikkapore_xm>...that's the thing; (current-processor-count) works, the expr that gets assigned to `parallelism` works in the repl, but running `cuirass-remote-worker` manually still reproduces the error?!? <parnikkapore_xm>by manually, I mean importing up the module in the guile repl (inside `guix shell cuirass`) and running the procedure <parnikkapore_xm>at this point I would not be surprised if a self-compiled cuirass correctly sets the parallelism <zimoun>By Guix convention, is %something an acceptable symbol inside a let binding for a variale? <nckhexen>I wouldn't call it conventional, but if you have a good reason… <snape>i think there's a convention for %var when var are global variables <snape>so i'd say if it's not a global var then it's against conventions :) <zimoun>snape: that’s my understanding too. <snape>hey folks, the guix QA/CI tools have really improved over the years, i'd say it's quite pleasant to use them. Congrats <snape>zimoun: no, but you can use (string-append version "a") in the first occurrence and version in the 2nd <mange>I'm seeing some buzz about a world-rebuild. Does anyone want to take a look at pushing https://issues.guix.gnu.org/49181#6 so modify-phases errors out if the before/after target phase is missing? At the moment it just adds to the end of the phases list, which doesn't really make sense. <mange>It's been hanging around for over two years. :-) <fnat>The error is something about "guild: no such option: -L" <rekado>fnat: are you trying to compile the shell wrapper…? <fnat>rekado: based on your question, I gather I should structure the project differently... :) I'm not willingly compiling the wrapper, I'm just using (possibly mistakenly) the guile-build-system against the current version of the project <rekado>fnat: the guile-build-system compiles all .scm files by default. If the shell wrapper is still called “whatever.scm” then it will still be compiled. <fnat>rekado: right, that makes sense, thanks, I managed to fix it block-listing the file <bdju>I have been seeing messages about some service lines in my config being deprecated for a while now but it didn't seem as obvious to correct as I'd hoped. is there any documentation on the change that needs to be made? in my case it's for dbus-service, udisks-service, and elogind-service <mirai>bdju: can you paste what you're seeing <mirai>if you're using dbus-service (the procedure) <mirai>it's simply unrolling them as (service dbus-service-type <the-config>) <efraim>I got the rust importer to not import yanked versions, now to see if I can get it to update within the same semver, ie from 0.2.1 to 0.2.3 and not to 0.3.8 <bdju>when changing (dbus service) to (service dbus-service-type) the reconfigure fails <bdju>error: dbus-service-type: unbound variable <bdju>aha. very nice. that just leaves two messages now. <mirai>you can peek at the definition of elogind-service <bdju>where/how would I do that? is there something like guix edit for it? <bdju>okay I figured out the udisk one no problem <mirai>most of are procedures of the kind (foo-service config) that return (service foo-service-type config) <mirai>so replacing them in this manner should work for most cases <bdju>/home/brad/dotfiles/guix/config.scm:114:24: error: (service elogind-service-type #:config (elogind-configuration (handle-lid-switch (quote ignore)))): source expression failed to match any pattern <bdju>not sure if I'm understanding but the first thing I tried did not work at least <civodul>bdju: hi! the syntax is: (service TYPE VALUE) <civodul>so in this case: (service elogind-service-type (elogind-configuration …)) <mirai>import the desktop module for elogind-service-type <bdju>ah, thank you civodul. that fixed it. <mirai>civodul: Hi! Does changing copy-build-system “install” procedure imply rebuilds on everything? <mirai>I'm looking into adding a #:output parameter to the install plan to support multiple-outputs <snape>that would be great though, that phases can be added on top of existing phases without triggering a rebuild of previous phases <mirai>nckhexen: Do you recall which package it was that had issues due to the unfortunate use of %gnu-build-system-modules ? <mirai>irc log search isn't helping me much here <nckhexen>snape: I agree, but how would that even work? <snape>nckhexen: each phase could have an intermediate store output? <nckhexen>(We weren't talking about adding phases causing rebuilds, though, but about *support for* adding phases being added to the build-side build system.) <nckhexen>snape: Feels fragile, but I've also considered it so maybe it's a good idea. <civodul>mirai: i’m not sure, you gotta try :-) <civodul>i don’t think ‘copy-build-system’ is used “deep down” in the dependency graph <snape>nckhexen: yeah I'm off-topic, didn't follow <snape>(but my point still stands ^^) <snape>is "guix shell --development guix -- ./pre-inst-env whatever" the correct way to use pre-inst-env in an hostile env? <nckhexen>I think so (at least not that hostile if it has guix!). <civodul>if it’s truly hostile, pass ‘-CP’ too (to get a container) <civodul>but yeah, it mustn’t be that hostile if it has Guix :-) <zimoun>mirai: Yes, I guess. LGTM, although I do not remember all the details of its context. :-) <jpoiret>ouch, didn't have time to read mail in more than 2 weeks <civodul>cbaines: i’m reconfiguring bayfront for the package-metadata changes i just pushed to maintenance.git <rekado>do we need to make a new cuirass release to deploy this or is it fine to push the fix to cuirass and then deploy it from that commit? <rekado>(this regression causes CI failures with the guix install action on Github) <civodul>on ci.guix, we only deply the ‘cuirass’ package <civodul>which means it has to be updated first <civodul>i tend to run it on my local instance before deploying on ci.guix, to gain more confidence <civodul>but if it’s an urgent fix (looks like it), i guess we can go ahead and update the package <jpoiret>do we have any news for the spot at the Capitole du Libre? <cbaines>on that note, I guess emails to guix-commits are broken for maintenance.git, as well as guix.git :/ <cbaines>actually no, I see the maintenance.git ones now <misa>hi. I want to repartiton my drive and install GNU Guix alongisde my debian install and do not know how to do it with both the graphical and shell install. Can someone pls help? <civodul>jpoiret: no idea; who’s taking care of it? <rekado>civodul: it’s been broken for a while; I don’t mind waiting for a good test. <rekado>I’ll push the fix today, but deploying to ci.guix can wait. <jpoiret>civodul: i don't know exactly, maybe andreas or zimoun <zimoun>no news back from Capitole du Libre, to my knowledge. <zimoun>well, I will try to drop them an email this evening. <jpoiret>i could possibly do something else on that week-end, that's why i was wondering. if it takes place i'll be there for sure though :) <mirai>it looks kinda crazy to do this by hand <snape>you don't have to do it by hand <snape>just copy paste what's given by git <snape>during the commit process, you have the list of files/hunks <snape>well it's not truly copy-pasting but it h elps <snape>(that being said i have no idea if in your case you need the monster changelog) <mirai>Right but the lines look kinda like `(package-name)[arguments]<#:modules>: Replace incorrect use of %gnu-build-system-modules.' <mirai>Doesn't look too trivial automating the (package-name) part <snape>(package1, package2, ..., packagen)[arguments]: Replace incorrect... <mirai>sure, I was mostly wondering if I could either skip this part or have something that could give me the package names automatically <mirai>rather than typing them one by one <snape>but you have the package names automaticcaly with git <snape>if you use a term you can just grep and with a small manipulation you'll get your list <snape>if you use emacs you can press "2" on the file name, then "M-x org-copy-visible" <snape>as for the "?? How", well, dark magic of git diff <apteryx>mirai: do you know of the 'C' trick in Magit? <apteryx>also, if some change was automated, simply mention the command used <snape>apteryx: is it only one hunk at the same time? <mirai>apteryx: nope, what does it do? <mirai>re automation, none was used <snape>it creates the "* gnu/packages/gnuzilla.scm (icu4c-73-promise):" line <apteryx>it fleshes out the rough location (at least file / function) <apteryx>from the diff hunk you're on, while editing the COMMIT_MSG buffer <apteryx>i'm acting on %default-gnu-imported-modules and %default-gnu-modules on core-updates <snape>mirai, there is also a yasnippet for this in <guix repo>/etc/snippets <snape>apteryx, mirai, it's even more powerful... just type update<TAB> <apteryx>or etc/committer.scm for simple upgrades <snape>well the snippet does some errors that 'C' gets right <apteryx>mirai: it's surprising the amount of people who stumbled on %default-gnu-modules <mirai>I've sent #66425 to address these <apteryx>OK; i'm somewhat duplicating the work but using %default-gnu-modules instead <apteryx>there's now %default-gnu-import-modules for the #:import-modules one <cdo256>Just to clarify, is following the steps in the 'contributing' section of the manual sufficient reading for submitting a patch? <mirai>default-gnu-modules isn't exported <apteryx>%default-gnu-modules; that's an upcoming change or core-updates <mirai>oh, I should have warned about #66425 sooner <apteryx>as well as %default-gnu-imported-modules <mirai>feel free to recycle the issue number if you have a better alternative <apteryx>hm, the teams.scm script is not exactly fast. maybe it should be byte compiled? <apteryx>it has a --no-auto-compile, for some reason <apteryx>rekado: perhaps we could do with the @GUILE@ / --no-auto-compile -s shebang (and let it use guile from PATH?) <apteryx>it'd autocompile itself, and that's OK (?) <apteryx>mirai see bug#65924 for the %default-gnu-modules change <apteryx>mirai: apologies for not realizing earlier you were pursuing this as well <apteryx>I guess on the plus side it makes it already mostly reviewied ^^' <nate1>This might be more of a general Guile question rather than Guix, but I have been trying to write a manifest for something that requires a Haskell program that depends on a specific old version of GHC. I wrote a little function to convert a package and its dependencies to that older version of GHC and it appears to work fine, but it remarkably slow taking many hours to compute. I'm really not sure <nate1>where I went wrong, and it seems to compute instantly in the repl, just not when running `guix manifest` <mirai>looks like I got myself into a rebase hell <snape>is there a way to manually trigger a build in qa.guix.gnu.org, after I fixed a dependency that was blocking the build? <cdo256>Would it be correct to say that "using shortened git commit ID's is possible but discouraged"? <cdo256>We only check if it's less than 7 characters. <GNUtoo>hi, I've some question about aarch64 kernel devices support. <GNUtoo>So far we have linux-libre-arm64-generic that uses arch/arm64/config/defconfig <GNUtoo>The advantage of that is that boards boot, but the disadvantage is that many modules are missing, for instance that config doesn't have wireguard. <GNUtoo>The linux-libre have the opposite: they have wireguard and so on but modules to boot are missing <GNUtoo>I've the list of such missing modules for at least 2 boards <GNUtoo>(a) Should I just the drivers required to boot to =y in the linux-libre arm64 Guix defconfig? The advantage is that it's simple, the disadvantage is that memory wise it's subobtimal as boards that don't use these drivers will have some of their code in RAM. <GNUtoo>(unless there is a mechanism I'm not aware of that also get rids of the code of these unused drivers somehow) <GNUtoo>(b) With linux-libre-arm64-generic, if we keep adding non-board specific support (like CONFIG_WIREGUARD) it will probably get out of proportion at some point. <GNUtoo>So I guess it's pointless to try to fix that? <GNUtoo>(c) Is there a mechanism to add modules per boards through the image types? <martin2020>Hi, is it possible to run guix system on Librem 5? <martin2020>theesm: thanks, I did read through that, but the conversation died off more than 1.5 years ago, so I thought maybe there is some info elsewhere? <GNUtoo>martin2020: I managed to boot Guix on the Pinephone that had Towboot by using grub, but it is missing some drivers (like USB3) <GNUtoo>But beside that mesa doesn't cross compile so most desktop environments don't cross compile, so you will need to at least do the installation in two steps <theesm>martin2020: afaik (don't own a librem 5 & last read upon it earlier this year) the librem 5 isn't mainline yet/there's not enough support in mainline linux to have it in a usable state (there seem to be quite a lot out-of-tree patches that have to be applied to have it somewhat work) <nckhexen>cdo256: In code, there's no reason not to use the full 40 characters (or more in future). <martin2020>Thanks. GNUtoo, how did you acquire/make the image you used for the pinephone? <efraim>GNUtoo: as someone using a pinebook pro and occasionally needing to build the kernel on the device, I'd rather start with linux-libre-arm64-generic and then add more support to it <cdo256>nckhexen: Ok, thanks, I'm just writing documentation for svn-fetch and the like. <nckhexen>(If by ‘we’ you mean ‘guix lint’ or so, I'd be happy to merge a patch that raises an error on 39 ☺) <GNUtoo>ACTION just pushed that and hopes that nothing is missing <GNUtoo>It's also a work in progress, like after changing some kernel configuration or updating Guix it doesn't find GRUB anymore, but I've an older image that boots <GNUtoo>So I'll try to look at the guix revision of that image later on <GNUtoo>Note that I've the serial port cable, so that simplifies a lot things as I can login into the console in this way and I see if it boots or not and why <efraim>the cable, I know where my pinephone is <GNUtoo>I'll try to upstream some minimal pinephone support in Guix <efraim>are you cross compiling it? I don't recognize that mesa error <efraim>ok, I see that error with cross-compiling <cdo256>nckhexen: I was referring to the definition of git-download, which I assume it's too late to change. But I'm having a read of lint.scm to see if that check is included. <nckhexen>OK, now I better understand where you're coming from. <nckhexen>That guard is there against typos (see comment) where it's not a git hash at all, by mistake; not because we'd generally accept shortened commit hashes in Guix. <nckhexen>(It wouldn't be too late to change, but it might be a bit extreme to enforce our full-hash preference on *all* users of Guix, not just our own packages.) <nckhexen>If someone wants to use short hashes in their channel or their dotfiles, that's their business. <cbaines>snape, probably, but that might also happen automatically, what's the specific situation? <cdo256>nckhexen: Sorry for the miscommunication :) <Minall>I'm reading about guix shell and I'm impressed, I wonder if there are blogs that talk about this when working with tools like docker, nodejs, frameworks like reactjs, and so on. <Minall>Wow, even a container separated from the rest of the system?? <- Checking the docs rn <Minall>So could it be used even like docker? <ohyllad>Is there some way to define elisp to be run on emacs startup in a package using emacs-build-system? <sneek>Welcome back ohyllad, you have 4 messages! <sneek>ohyllad, antipode says: The idea is that '%with-resource' would be moved into Guile proper, and that Guile-Fibers would override it. <sneek>ohyllad, whereiseveryone says: We had a nice guile debugging session today with ludo at Guix Days <sneek>ohyllad, zamfofex says: If you haven’t seen it yet, check this out: <https://paste.debian.net/plain/1286453> (It should work on latest Guix!) Just: ‘guix shell -f automake.scm’ (where ‘automake.scm’ is that file downloaded on your file system) <civodul>Minall: hi! i guess it depends on how one uses Docker, but yes, ‘guix shell’ can cover some of the use cases <apteryx>if you don't use 'docker compose', guix shell can pretty much replace docker <apteryx>docker also can do dirty gluing of random bits together, which guix would have you solved via cleanly packaging the software <Minall>That's amazing, I'm reading about it... Even GUI packages, if I need to do pentesting I could also make a container <Minall>Can this container e used for malware analysis? <lilyp>I mean, as long as you assume your malware can't escape the container? <apteryx>is this handled by (guix substitute) or something else? <lilyp>Note that malware does like to break sandboxes <lilyp>it won't have internet by default, though <Minall>I'm pretty surprised on things that I'm reading atm. I will later take a look at what pentesting things are available and how to implement some if they are not <lilyp>it also won't have most of your GUI environment variables out of the box; you'll have to explicitly and painstakingly grant these permissions <Minall>But I'm interested since having a configuration that I can have in any pc is cool since I shouldn't hd to set up by 0 exwm and other things <noobly>i had an installation failure a few weeks ago and posted the info to the guix server by following the prompt. I wrote down 'installer-dump-08cf3d5b' as the name of my issue, but i dont' know where to search for it. any help? <Minall>Is the technology used for the containers docker or similar? <Minall>Since there's a lot of systems like freebsd or openbsd with their own ways, like jails and vm <apteryx>rough plan for adding gnunet support: 1. add gnunet-service-type 2. expose /var/cache/guix/publish via gnunet 3. add gnunet support to guix-daemon <apteryx>or more specifically (guix substitute), which guix-daemon uses <apteryx>since the files are already uniquely named, they could simply be looked by that name; perhaps optionally with a zone correponding to 'berlin' or 'bordeaux' for example to know of their exact origin <cbaines>I think baking nars on berlin is done via guix publish, not cuirass (although my information may be out of date, and I think cuirass uses guix publish) <apteryx>I found out it doesn't matter in the context of gnunet <apteryx>we can simply expose whatever has been baked and put under /var/cache/guix/publish, right? <cbaines>I think the case of an arbitrary substitute server for some channel is more useful to think about <cbaines>for example, in the above plan, do you always query gnunet for nars when you want to fetch, or is it worth doing something like having something in the narinfo about gnunet? <cbaines>(there's already information in the narinfo about different compressions and where to fetch them from) <lilyp>Minall: IIUC they both use plain "old" Linux containers underneath <cbaines>there's definately been more thinking about approaches for this in the past though, and I think there's a whole spectrum of approaches with different comprimises. For protocols like gnunet, it might be worth serving individual store files rather than nars for example. <Minall>Interesting. I wonder how old the approach is, I mean, old is not bad <civodul>in other news, the build queue at ci.guix is almost empty! <singpolyma>Ive used guix on arm a bit, but lack of substitutes makes it mostly a nonstarter <rekado>apteryx: I’d guess that the git part is slowest. Have you profiled the script and/or run a byte-complied variant to see how much of an impact it makes? <rekado>I had a pretty good experience with Guix on aarch64 <rekado>substitutes come mostly from bayfront <singpolyma>rekado: you managed to get substitutes on aarch64? That would be a game changer <cbaines>singpolyma, we have more substitutes for aarch64-linux than i686-linux (at least by percentage) <singpolyma>Hmm. I will have to try it again then. Maybe I won't spend a week compiling inkscrpe just to install anything this time 😅 <cbaines>that could be misleading as it's several days out of date at this point :/ <civodul>though the numbers must have remained similar over the last few days <snape>icecat is blocked by icu4c, which I fixed on master <cbaines>snape, if it's been fixed since Monday, the data service doesn't know about that yet <snape>the data service refreshes every monday? <cbaines>the data service relies on the guix-commits mailing list, which seems to not be working (since Monday) <cbaines>this has happened before, and I've always thought "I should get the data service to poll", but I haven't got around to it yet <cbaines>I think I nearly have polling implemented, but it's segfaulting at the moment <snape>oh, ok. When it's fixed, will an example like the one i showed you auto-repair? <mirai>what was the URL or command to fetch the last (or some specific) revision for a patch series? <cbaines>snape, eventually, but it might not be very quick. Doing it promptly will either require resending the patch series or deleting the guix-patches branch so that it's re-applied to a newer master revision <cbaines>I also want to look at making QA smarter about detecting when changes on master impact the patch series, so it can automatically re-apply patches to a newer master when appropriate <snape>meanwhile it's stuck on a specific sha1 and i'd have to re-send platch to force it on a newer commit. But i won't since it's stuck anyway <snape>great work cbaines anyway, great work, this is useful. <ulfvonbelow>when generating graphs via dot during 'make', I get this error message: Error: fontconfig: Didn't find expected font family. Perhaps URW Type 1 fonts need installing? <ulfvonbelow>I'm in a 'guix environment guix', so not sure what I'm missing <Minall>In a guix shell container environment, could one run databases? <mirai>ulfvonbelow: it doesn't abort the make process iirc <mirai>but if you feel like investigating start with #65741 <Minall>Is there a way to add my wifi firmware to the installer?, sadly this network device is non free but, I don't have any cable and I really want to try gui <graywolf>Minall: There is a Guix channel that does allow that, yes, but it cannot be named here. Try searching the web for it. <Minall>On it, thank you. I need to get rid of this non free device <apteryx>rekado: the git part is slowest yes; although I'm not sure why (haven't profiled it yet) <apteryx>it's something like 1 s per commit or maybe 0.5 s, very visible for large submissions <snape>civodul: why is guix shell faster than guix environment? <snape>oh nice, i'll read this, thx <Minall>Omg guix comes with EXWM as option. Amazing <ieure>Oh, you're also an EXWM user? <ieure>I'm always excited to find other people unhinged enough to use EXWM. :) <Minall>Is the guix package for Emacs usable?, seems to be 2 years old since the last release <graywolf>Maybe you are on old guix version? (--> guix pull)