IRC channel logs

<vhns>Is there really no i8kutils package? I refuse to believe no on ehas had to adjust their laptop fans before

<ekaitz>vhns: why don't you package it?

<ekaitz>i8kutils it's only for some dell laptops, we have many other programs for fan control

<vhns>ekaitz: I meant it in a way of "Am I searching for the package improperly?" not a "REEEEE PEOPLE SHOULD PACKAGE STUFF FOR ME!"

<vhns>I have packaged/submitted changes to guix before

<ekaitz>vhns: it doesn't look very hard to package, you can probably do it very fast if you have contributed before

<ekaitz>vhns: if you do, cc me with your patch and I'll commit it

<ekaitz>you have to understand that we don't have that many users and many things are never packaged because nobody uses them or we are left with old software

<ekaitz>or even broken software (missing functionality, extensions, plugins...) because nobody uses some programs extensively

<ekaitz>it happens a lot and makes a lot of sense

<vhns>ekaitz: what is your e-mail?

<ekaitz>search my nick in the guix codebase copyright headers or commits

<vhns>ok

<ekaitz>my nick is literally my name (yes, i have a weird name :) )

<jab>sneek later tell dthompson "I am trying to get haunt to work on openBSD. I got guile-commonmark installed, but trying to run make on haunt...gave me some errors."

<sneek>Will do.

<jab>sneek later tell dthompson "specifically the texinfo file. It's probably something I did wrong."

<sneek>Got it.

<jab>sneek later tell dthompson "I was able to install haunt on OpenBSD. I just commented out haunt's texinfo file in the makefile."

<sneek>Got it.

<apteryx>sneek: later tell mghackerlady re gnome updates; there's a gnome-team if you'd like to join and contribute to keeping our GNOME stack fresh. Some packages can already be updated to version 48, but in some cases it'll need some bigger libs updates, such as glib or gtk or the likes.

<sneek>Got it.

<apteryx>can I pre-process the list of file-likes (gexps) passed to file-union?

<apteryx>untested, but you get the idea: https://paste.debian.net/1373148/

<nomike>I'm upgrading openscad and for that I need to add a new package "manifold". I remember reading somewhere in the guix manual, that patch-submissions should be small and it should be avoided to submit multiple changes simultaneously. So I submitted a patch for adding ,manifold a four days ago, which is still unanswered. It is a dependency for the new openscad version which I just finished.

<nomike>Should I have submitted them together? Do I need to wait now for manifold to be merged before I can submit the patch for openscad?

<nomike>What's the best practice here?

<ieure>nomike, Depends on the dependency being updated, but I often include required dep bumps in a patch series.

<kjartanoli>nomike: I am pretty sure you could send the patch for openscad and mention that it is contingent on the update to manifold.

<meaty>any python packagers around right now? I'm trying to update calibre and I'm getting the message "bdist_wheel is not a recognized command" even when python-wheel is in my native-inputs

<meaty> http://paste.debian.net/1373154 this is my (very preliminary) package definition

<meaty>It appears that its build system has changed a lot since its last update in guix three major versions ago, so I can'r recycle the old def

<meaty>A quick 'rg python-wheel' says it's typically added to native-inputs alongside python-setuptools, but that doesn't fix it

<apteryx>meaty: usually adding wheel would fix that

<apteryx>so I'm not sure :-/

<apteryx>get I build a list in a gexp, and have this computed on the spot, to return the computed list instead of the gexp object?

<apteryx>how can I *

<auk>meaty, this is the problem: https://discuss.python.org/t/upcoming-changes-in-the-pypa-wheel-project/85967/1

<auk>at least, i think so. Sounds exactly the same

<auk>basically the problem is entirely an upstream issue caused by recent versions of `wheel` being incompatible with certain versions of `setuptools` ...and nothing to do with guix

<meaty>auk: dang... what can be done then?

<meaty>is there a trivial way to patch around it?

<auk>meaty, i think just pin your versions of setuptools and/or wheel to a known-compatible pair

<auk>(but idk if that's practical in a guix context)

<auk>i am not a guix packager, i'm barely getting started with guix

<auk>well... i guess guix will probably definitely want to do this, to prevent a "bunch" of packages from breaking

<auk>meaty, you could also patch your specific package to use `from setuptools.command.bdist_wheel import bdist_wheel`

<auk> https://discuss.python.org/t/upcoming-changes-in-the-pypa-wheel-project/85967/7

<auk>presumably that would work

<apteryx>meaty: maybe you can workaround the issue and use a different pep 517 builder, if the package as a pyproject.toml file?

<apteryx>has a*

<apteryx>wow, that's a complex piece of software, judging by the sheer amount of inputs

<meaty>auk, apteryx: yes, it is dizzying lol. but I can't even get started if it's stuck on wheel. wdym a different builder? Also, I grepped its codebase and couldn't actually find the word "wheel" used in the context of building/configuring

<meaty>Also, the inputs in my working copy are based off of https://github.com/kovidgoyal/calibre/blob/master/bypy/sources.json , which may or may not include dependencies of the python modules? so there might actually be a lot less inputs. I plan to pare it down, though, once I actually have it building

<hiecaq>TIL that if I incorrectly use a git ref that doesn't belong to the repo of the package, Guix will download the repo it actually belongs to from software heritage. A little bit scary tbh ... https://paste.debian.net/hidden/0db9be4d/

<ieure>hiecaq, Yeah. Pretty much has to be like that.

<ieure>hiecaq, We want packages to keep building even if the original location of the source doesn't exist. So in the case it can't be found, it uses the SHA to look it up on a content-addressed mirror.

<apteryx>I think I came up with what I had on mind. It's a bit over the top, but educative: https://paste.debian.net/1373167/

<apteryx>I wanted to use a list of file-like as input and expand it to a list of actual files to be passed to etc-service-type.

<ruther`>apteryx: what are you working on with those profile.d files?

<apteryx>vte integration, which needs making /etc/profile extendable (I've chosen the profile.d path for this)

<ruther`>apteryx: interesting. Yesterday I made a patch for extending /etc/profile like that as well, but I havent submitted it yet since I was too lazy to test it.

<ruther`>there have been discussions about extending it in the past and it was never settled.

<apteryx>OK! I'll CC you when I submit if you'd like

<ruther`>So I was planning on sending it to the devel list for discussion first

<ruther`>My idea was to actually make two possibilities to extend it, one is to use /etc/profile.d and the other is to use the system profile - /run/current-system/profile/etc/profile.d

<apteryx>I'm using /etc/profile.d, via an etc-profile-d-service-type, that accepts file-like objects

<apteryx>this extends etc-service-type

<ruther`>the latter basically solves the problem you have, that you don't know the files before they are built, and you have to use store connection, which is definitely not a good approach as it means this has to be first calculated before the build can start - it is dynamic dependency

<apteryx>ruther`: if I go a custom computed-file instead of the complicated code I've shared earlier, then everything will be deferred alright

<apteryx>basically implementing a specialized variant of file-union that extends etc-service-dir as (list "profile.d" (computed-file ...))

<apteryx>I'm working on it atm

<apteryx>(it'll be less precise in the checks it can do, but good enough, I think)

<ruther`>sure, that means you will make a new 'profile.d' service?

<apteryx>yes

<ruther`>sounds good then!

<apteryx>and then I'll use it to implement a vte-integration-service-type, that'll take just the vte package

<apteryx>or vte-service-type, perhaps. names :-)

<ennoausberlin>Hello, Guixers. I at the moment move from self hosted gitlab to self hosted gitolite + trac architecture. I wonder if it is possible to use ssh to fetch channels from gitolite. I always get key exchange errors when I try so. I am aware of https://issues.guix.gnu.org/77154 and updated libssh2 by myself, but it does not help. Are there guix fetch

<ennoausberlin>internas involved I am not aware of? Cloning from the gitolite server works well, but I guess my ssh keys are not exposed during channel pulls

<auk>TIL the author of calibre and kitty is the same

<auk>i also had no idea calibre was so complicated

<auk>hiecaq, yikes, that is kind of scary

<auk>this is really cool, but seems like it would be good to provide an option to disable it https://guix.gnu.org/en/blog/2019/connecting-reproducible-deployment-to-a-long-term-source-code-archive/

<apteryx>ruther`: I've made an initial test in my operating-system config with (service etc-profile-d-service-type (list vte)), it works well. I also added a basic test to our existing 'basic' system test.

<auk>meaty, it could be a transitive dependency i guess?

<auk>is the calibre build fully hermetic? (is setup.py prevented from accessing the internet?)

<df>wasn't there some move towards making git use a more secure hash than sha1?

<auk>df, you mean upstream? I thought they just patched sha1

<df>gpg-signed commits are an option of course, but if they don't happen automatically most people won't use them

<df>auk: I don't know tbh, I just vaguely remember hearing something

<auk>but even if the hash is perfectly secure, there's still the problem that hashes are not human-readable. It's nice sometimes to have a builtin 2-factor redundancy: hash and url/depot

<auk>*"even if the hash algorithm is perfectly secure"

<yelninei>yikes, just got a data corruption on my current-guix profile with a "unsupported manifest format" (the file was just empty) and I could not roll-back or rebuild it and my channels were gone.

<df>nice, but is it necessary if you do have a secure hash from a source you trust?

<df>I guess I'm asking what's the threat model here

<auk>i regard git hashes as reasonably secure (given whatever patch they did to sha1), but i haven't looked into it recently

<yelninei>force deleting the gcroots and the profile entry and now I fixed it again, but things were scary at first and I dont know what else is corrupted

<df>I think it's generally agreed that sha1 won't last forever though

<auk>df, my threat model here is "i have hashes in my package definitions that I may have copy-pasted from who knows where"

<auk>or rather, "that someone else may have copy-pasted from who knows where, when creating the package"

<auk>so it's nice *sometimes* to have the second factor of "this hash actually exists in the expected repo"

<df>I see

<df>but isn't the expected repo the one the package creator took the source from?

<auk>meaty, have you looked at guix's package definitions for python-setuptools and python-wheel? if you can pin those two a known-good version pair, you *might* fix your bdist_wheel problem

<auk>df, right. But then, if i understand correctly, guix is querying software heritage for the commit hash, "from any repo that ever existed anywhere"?

<df>it seems to me that would be fine if you were confident that the hash was secure

<auk>meaty, if you fix setuptools and wheel, you might also fix this for a bunch of other python packages. Also you could try filing an issue with calibre upstream. This issue is probably affecting all their builds -- upstream, other distros, etc

<auk>df, agreed, if you're 100% confident the hash is accurate, then it's strong enough as a single factor

<auk>(afaik, haven't looked into git's sha1 it recently)

<df>and I'm not in any way confident that sha1 is secure against eg a nation state

<auk>fair enough

<df>but I think a strong hash is a pretty strong single factor

<auk>i think guix's behavior is probably good as a default. But it would be nice to have an easy option to disable (maybe it already does?)

<df>no idea offhand, use the source :p

<apteryx>does gdm source /etc/profile?

<apteryx>or gnome-shell

<apteryx>it seems to do it in Fedora

<auk>df, oh i think i was vague earlier. I meant "git patched their own sha1 for their use case", not "sha1 algorithm has been patched"

<auk>looks like git is moving to sha256 and also to abstracting the hash code to enable changing again in future

<df>that's good news

<df>isn't sha3 a thing now though?

<auk>it is, but i guess it's less respected than SHA2? https://en.wikipedia.org/wiki/SHA-3#Weakening_controversy

<auk>a good, scalable way to prevent collision attacks is a data size check. As i understand it, in a lot of cases this can exhaust the attack space completely, leaving no room for collision attacks

<auk>you avoid the algorithm treadmill that way

<auk>but still, algorithm collision attacks are not what concerns me

<auk>you said "isn't the expected repo the one the package creator took the source from?" and i agreed... but on second thought, i'm not sure that's true

<auk>if guix's fetch from SWH is enabled while a packager is crafting a definition, then the packager won't necessarily get feedback from the tooling if they accidentally put in a wrong hash

<auk>do we expect packagers to be meticulously double-checking the git hashes they are copy-pasting, with an eye to "have i retrieved this hash from a trustworthy source?"

<auk>you go, you grab a commit hash from whichever web UI -- maybe with several mirrors -- you put it in, guix uses it, grabs it from ...somewhere...anywhere... and keeps going

<auk>this attack is a lot more boring and more practical than hash collisions

<Guest79>hi, anyone has a quick reference on how to run a guix installation in a container? i wanna experiment with my config in a container not on real hardware

<identity>Guest79: read (info "(guix) Running Guix in a VM")

<csantosb>There is also (info "(guix-cookbook) Containers")

<mccd>Heya, I'm running into the issue: `ENOTCACHED npm error request to https://registry.npmjs.org/@emmetio%2fexpand-abbreviation failed: cache mode is 'only-if-cached' but no cached response is available.` when trying to build a simple node package

<sneek>mccd, you have 1 message!

<sneek>mccd, homo says: sqlite package provides libsqlite

<mccd>Any tips for how I might debug it?

<mccd>Is it that I need to package each and every dependency as well?

<civodul>Hello Guix!

<sneek>civodul, you have 2 messages!

<sneek>civodul, rlb says: looks like there's also an rdelim.test failure a bit further down, and don't remember anything offhand.

<sneek>civodul, csantosb says: what about a .editorconfig in guix-science ?

<mccd>Okay, I have to package all node packages individually. Hmm, this seems to be different from Nix. Or does Nix have some script that automatically packages all dependencies as well?

<ruther`>mccd: It is different. see guix import for importing npm binary packages with deps

<jlicht>hey guix

<jlicht>currently working on getting the soon-to-be-released node 24 packaged. I also submitted an NLnet proposal to get the node bootstrap in a better place than it is now! :)

<mccd>ruther` ah that's great, almost worked except for a stupid mocha and rollup dependency haha.

<mccd>I'll work around it for now by using `npx my-tool`

<efraim>jlicht: I'd love to hear more about that. I have a WIP branch of riscv64 support in node-12

<Guest79>is there a way to specify different versions of the same channel and draw specific packages from those different variants?

<Guest79>like in nix flakes?

<hako>see inferiors in the manual

<look>you can also use guix time-machine and pass different channel.scm files containing different commits for each channel, if looking for a more "shell" approach

<richardjacton>Hi I'm new here, and also to IRC so still getting used to the interface / etiquette

<richardjacton>I'm having some trouble with guix git authenticate and was looking for some help troubleshooting

<richardjacton>I just started a new repo and followed the steps in this post: https://guix.gnu.org/en/blog/2024/authenticate-your-git-checkouts/

<richardjacton>running guix git authenticate command with key and introductory commit seems to work on the commit that adds the .guix-authorizations file

<richardjacton>but on subsequent commits exits with this error: guix/ui.scm:819:18: #<unknown port>:9:1: unexpected end of input while searching for: )

<richardjacton>I looked up the location in the code where this appears to be comming from in savannah but can't make any sense of it: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/ui.scm#n819

<yelninei>richardjacton: Check the parentheses in your .guix-authorizations file, i think you may be missing a ")" somewhere

<richardjacton>Thanks - Ok will do.

<K0nrad>I'm stuck running guix reconfigure. I've pulled from the codeberg mirror (I don't know whether that's relevant), but on running guix reconfigure, I'm getting an error: Git error: SSL error: syscall failure: Resource temporarily unavailable on ice-9/boot-9.scm:1685:16: In procedure raise-exception.

<richardjacton>Ah ha - yup missing a closing paren - not used to guile yet, lots of parens! will just redo those commits and check that fixed it.

<yelninei>richardjacton: if there is an error youd need to adjust the introuctory commit as well because the file needs to be valid for every commit inbetween the introduction and the one you are trying to authenticate

<K0nrad>Ah, now I see it doing something.

<richardjacton>Thanks for the help I ammended the commit history and got it working!

<richardjacton>However just running guix git authenticate returns guix git: error: wrong number of arguments; expected COMMIT and SIGNER and there are no changes to the git hooks like the post indicated there would be after the first use. Is there something I can do to trigger this manually?

<yelninei>the commit and signer sould be written to .git/config , but maybe is something wrong because of the previous wrong thing?

<richardjacton>hmm there was not any change to .git/config, so I added what it says to expect there in the manual https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-git-authenticate.html and no change to the behaviour when I run the command.

<richardjacton>Maybe I've got an old version of guix or something, I installed it from the 24.11 branch of nixpkgs wierdly the output of guix -V doesn't acctually contain any version information

<andreas-e>richardjacton: Maybe you forgot to do a "guix pull"? This should be the first action by any user invoking the "guix" command.

<yelninei>that could be it, you could try to 'guix pull' first, the last release is a bit old

<richardjacton>ah right the 'core' guix itself seems quite up to date, 1.4.0 with a couple of security patches in the 24.11 branch but I assume some of the scripts it runs are pulled from the guix channel so might be lagging if I didn't do a pull?

<andreas-e>1.4.0 is super outdated :)

<andreas-e>Guix is really rolling release, without a "guix pull" one should not even start.

<andreas-e>Hello iyzsong! I noticed a few probably annoying build failures in qt-team.

<andreas-e>It looks as if tex-team could be ready to merge a bit earlier in the end.

<richardjacton>Thanks, I see just went off 1.4.0 is the most recent version that's not 'latest' on the site that there's a release for. I've not found it documented anywhere is there a schedule / policy for cutting a numbered release?

<iyzsong>andreas-e: sure. it seems more updates are needed for KDE packages, i'll contact kde-team soon

<andreas-e>richardjacton: We are working on it™

<richardjacton>OK good to know

<andreas-e>But even then one needs to "guix pull" regularly. We have no separate stable branch with security updates, for instance.

<andreas-e>So the numbered releases really just serve for installation; and having one could be good marketing to show that there is progress.

<andreas-e>This explains why in the end there is little motivation to make releases.

<attila_lendvai>andreas-e, isn't it so that not any version of guix can pull any other versions (think of bootstrapping issues). and if so, shouldn't the versioning scheme provide consecutive stages through which any old guix installation can pull?

<attila_lendvai>*pull all the way to the latest

<andreas-e>I am not sure what happened before version 1.0, but I am rather confident that any later version can "guix pull" to a current one. In any case, one can easily "guix pull" from 1.4.0.

<richardjacton>makes sense given how it's architected, I'm just new to acctually using it - mostly been a nix user

<mccd>I'm trying to apply a patch to an existing package, I've inherited the package and added the source

<mccd>(source (origin

<mccd> (inherit (package-source aerc))

<mccd> (patches '("001-aerc-remove-transactions-requirement.patch"))))

<mccd>but I'm noticing that it says File X is read-only; trying to patch anyway, and then it fails because the source code is read-only

<mccd>is there a way to allow applying patched?

<mccd>patches*

<pastor>Hello. Is xdg-open broken for KDE? As well as kde-open which xdg-open uses internally.

<Kabouik>civodul: what was the solution teased in the last sentence of this blog post? https://hpc.guix.info/blog/2017/09/reproducibility-and-root-privileges/ It's from 2017 so it was probably posted already.

<civodul>Kabouik: hi! i guess it was ‘guix pack’

<civodul> https://hpc.guix.info/blog/2017/10/using-guix-without-being-root/

<Kabouik>Makes sense, thanks!

<Kabouik>Well it was just the next blog post, I didn't expect that, sorry for making you look for it

<gabber>can/do make-flags in gnu-build-system overwrite the `FOO_BAR = some value' lines in Makefiles?

<ruther>gabber: make flags literally means flags put to make command. So no, it can't, only ?= assignments are overriden by make XYZ=...

<gabber>ruther: thanks!

<gabber>so i'll substitute the line in the Makefile

<Tadhgmister>if I have 2 machines that independently use 95% the same operating system configuration and I want to extract out the differences as a mixin like construct is there a clean way to do that that doesn't require the common code to know which fields are being touched by the mixin?

<graywolf>I have a "base" system, and two procedures called system-a and system-b, use in the following way: (system-a %base) and (system-b %base).

<graywolf>But my systems are quite similar, so I am not sure if that would work for you.

<Tadhgmister>I was thinking that but the hostname is one of the things that is overriden and would be required in %base

<Tadhgmister>I guess I just specify a dummy hostname that gets overriden? that isn't as complicated as I was originally thinking it just seems inelegent

<graywolf>Ok, so little twist, my %base above is actually a procedure (basic-system) that takes the required fields.

<graywolf>Signature is:

<graywolf> https://paste.debian.net/1373252/

<graywolf>I can just override those that I need, e.g. `name' is passed to `hostname'.

<graywolf>Maybe not the ideal way, but seems to work well enough

<Tadhgmister>oh yeah ok that makes sense, define the common code as a procedure that takes non mergable fields info to be provided by the mixin and then the mixin also merges its own details afterwards

<Tadhgmister>definitely not super elegant but totally workable for my purposes

<vagrantc>wow, git bisect with guix build --with-commit=PACKAGE=COMMIT is awesome.

<ieure>vagrantc, Yes, really good stuff.

<nomike>hi

<nomike>I'm getting a "error: cannot convert from yes to UTF-8\nfatal: could not parse patch" from mumi when I try to am 77913. It looks like a bug in mumi. Could someone confirm this please? https://paste.debian.net/1373255/

<ngz>Hello Guix

<Tadhgmister>hello

<ieure>Hi.

<nomike>hi

<Tadhgmister>where/how would I find the code responsible for the guix daemon writing files to the store? I'm trying to establish how to properly setup tmpfs for the builds and then btrfs compression for the store

<sham1>I was under the impression that the guix-daemon defaults to using /tmp for builds by default. IIRC the nix-daemon does that and I have no reason to belive that guix-daemon wouldn't follow suite

<sham1>btrfs compression for the store should be easier. For example you can have the store be on its own subvolume and then mount it with compression on

<nomike>Tadhgmister, I can confirm that guix-daemon uses /tmp for builds. I'm on Ubuntu foreign distro and my computer had lots of issues with kagginess, crashing and out-of-memory situations until I figured out Ubuntu is using tempfs on /tmp per default. I turned it off and since then everything is fine again.

<nomike>But that took me some time to find.

<nomike>and I have 48 GiB RAM which should be plenty. So be sure that you really want to tmpfs for your builds.

<Tadhgmister85>ok that is good to know, ty

<Tadhgmister85>guix/nix/libutil/util.cc uses `getEnv("TMPDIR", "/tmp")`, so I might be able to give the guix-daemon a different TMPDIR environment variable as everything else

<Tadhgmister85>but just mounting /gnu with the compression flags I want should be sufficient right? I just know there is weird mounting stuff to make /gnu/store readonly outside of the build daemon so want to understand that the build daemon will respect the compression options

<zuki>hey anyone know how to configure font config in guix?I did this on gentoo via /etc/fonts/local.conf but since guix is guix I assume there is a guix module or such for doing so, although i can't find it with a few searches.

<ruther>Tadhgmister85: that read only mount is only a bind mount

<luca>zuki: there's https://guix.gnu.org/manual/devel/en/html_node/Fonts-Home-Services.html for users at least. Not imediately sure about system wide configs

<zuki>luca thanks

<auk>ieure, relating to the what hiecaq said about guix pulling source content-addressed from SWH -- i think i might have a conceivable exploit scenario

<luca>hi, does guix have any sort of opt in telemetry? Such as reporting what packages and versions of packages a system uses

<ieure>luca, No.

<sham1>Yeah, no equivalent to for example Debian's popularity-contest. Although I have no idea what the guix maintainers would even do with that information even if they could collect it

<sham1>Best bet might be to scream one's GC roots into the void, because that of course shows what you explicitly have installed. Or taking part in user surveys like the one conducted last year

<sham1>Speaking of, time to update the channel pins

<nomike>How can I send a second version of a patch with mumi? With `git send-email` I would do `git send-email --annotate -v2` but I can't find much documentation on mumi rather then `--help` and a few sentences in the guix manual in chapter "22.11.3 Debbugs User Interfaces"..

<ieure>nomike, Just a guess, but probably adding `-- -v2' to the end of the mumi commandline does it. But I don't sent patches with mumi, so I could be wrong.

<Guest79>hi. is there a way to make the iso generation module use multiple cores?

<Guest79>`guix system image -t iso9660` is taking too long because its using only one core (its running `xorriso`)

<nomike>ieure, unfortunately this doesn't work. It's only giving me the git send-email usage page.

<ieure>Guest79, You'd have to patch xorriso.

<ieure>nomike, No idea then.

<Guest79>leure, is there a different way to generate an iso that isnt that slow?

<nomike>I will do it manually with `git format-patch` and `git send-email` for the time being and will ask on guix-help.

<ieure>Guest79, No.

<ieure>Guest79, If it's to the xorriso bit, it's copying data into the image; this isn't usually the slow part.

<Guest79>i mean `xorriso -as mkisofs -graft-points --modification-date=2025050519554700 -b boot/grub/i386` its been running for quite some time

<Guest79>maybe i should mention the fact that im building an iso with my whole system in it (all packages i use)

<sham1>...that would take a while, yeah

<Guest79>hmmm

<sham1>Like, how large is your /gnu/store

<Guest79>no idea, installing for 1st time

<Guest79>i mean, not first time, but i dont have guix running

<Guest79>just using the binary

<Guest79>ok ignore that, it shouldnt matter lol

<Guest79>im checking rn but its taking some time

<Guest79>oh its 33g

<Guest79>wait no its 45gb

<sham1>Yeah, so no wonder building an ISO takes a while. Of course, the size of the store isn't everything, since it's only really reflective once you do a gc on it, but one could imagine that the resulting image would be quite many GiBs

<sham1>That's why the install ISO is specifically configured to be quite slim (IMO a bit too slim, which is why I for example forge my own with an actual graphical interface and Emacs (and some tainted bits))

<PotentialUser-28>Hi, I'm trying to get a minimal ocaml guix shell set up. When I invoke guix from the CLI the default version of ocaml provided is 4.14.1 but I can say `guix shell -D "ocaml@5.0.0" dune` to get a later version. In my guix.scm file if I say `(native-inputs (list "ocaml@5.0.0" dune))` this still tries to pull in ocaml-4.14.1 instead. What's the

<PotentialUser-28>correct syntax for specifying the version in the guix.scm file?

<ieure>PotentialUser-28, Figure out what module OCaml stuff is in, use it in your guix.scm, put the variable the 5.0.0 package is bound to in the inputs list.

<PotentialUser-28>ieure Thanks, this is in the ocaml package, so you mean to say I'd use the part after define-public -> `(define-public ocaml-5.0`?

<ieure>PotentialUser-28, Yes, if the code is (define-public ocaml-5.0 (package ...)), then `ocaml-5.0' is the variable the package is bound to.

<ieure>PotentialUser-28, I'm not sure about the context you're running in, but (native-inputs (list (specification->package "ocaml@5.0.0"))) may also work.

<PotentialUser-28>It looks like this is still getting the older version `(native-inputs (list ocaml-5.0 dune))`. I get an unbound variable error for specification->package using `(native-inputs (list (specification->package "ocaml@5.0.0") dune))`

<ieure>PotentialUser-28, Is dune an OCaml package?

<PotentialUser-28>Yes, but I think I see what I was getting wrong. It looks like it's requesting both the 4.14.1 and 5.0.0 versions, but the `ocaml-5.0` syntax is correct

<PotentialUser-28>I appreciate the help here

<Tadhgmister>when I install brave through nix it seems to only have fonts if I make a symlink from `~/.local/share/fonts` to `~/.guix-home/profile/share/fonts`, is there a way to make it happy without that workaround or a way to indicate I need that symlink in my home-config?

<Tadhgmister>weirdly it also works when I do `guix shell fontconfig font-gnu-freefont` and then in the shell `fc-cache && brave` but I cannot for the life of me figure out how that works but having those packages installed to my home configuration does not

<graywolf>Hm, so after guix pulling, I now cannot build guix from source. `autoreconf -vfi' gives me `autoreconf: cannot create /tmp/ar12.22: Read-only file system'. I will "solve" this by the --writable-root, but I am not sure whether this is expected or not.

<graywolf>civodul: Sorry for the ping, but since you are the author of ce363c1dc7bd63a74dcf7788d340819f6d5db89f I though I would let you know

<civodul>graywolf: hi! it’s a bug; could you send it to bug-guix?

<graywolf>Yeah RO /tmp felt weird, just wanted to make sure

<graywolf>Will send the report

<civodul>thanks!

<graywolf>Done, #78272 .

IRC channel logs

2025-05-05.log