<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
<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
<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.
<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
<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`
<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?
<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?
<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!
<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