IRC channel logs

<identity>orahcio: (file-append bash "/bin/bash") is indeed "a more Guix-like way"

<Kabouik>I am trying to install a Windows VM using virt-manager but I am getting this error: https://0x0.st/8DFW.txt What am I missing, knowing that I already ran `virsh net-define … && virsh net-start … && sudo herd restart libvirtd` and have https://0x0.st/8DFx.txt in my config.scm?

<Kabouik>Oh, I guess it's not actually using libvirtd but virtlogd (I didn't know there were two services) and I might need https://0x0.st/8DFg.txt

<Kabouik>Yes, that was it. And I also added "kvm" to (supplementary-groups …)

<Kabouik>Hurts me to install a Windows VM anyway.

<apteryx>something appears to have changed as to how Emacs indent scheme code; nested expressions now appear to be indented by 2 spaces (hanging indent) instead of 1 :-/.

<Kolev>A graphical live system would be nice.

<apteryx>is it possible to download the GPG key of someone from their codeberg profile?

<apteryx>if not, it's still important to maintain a presence on Savannah with an up-to-date GPG key (this is the trusted place we can rely on to get someone's GPG key).

<bhoot>Hi. Is there a way to tell `guix pull` to update only one specific channel? My aim is to be able to frequently pull my personal local channel for quick iterations of package development.

<bhoot>I have appended my channel definition in ~/.config/guix/channels.scm

<Rutherther>bhoot: not really a straightforward way, you need to guix describe -f channels and remove the commit from the channel you want to update. Then pull from the file you just created like that

<bhoot>thank you. Then what is the best way to quickly iterate over a package under development? Loading from a local file seems to be it to me.

<Rutherther>identity: I don't understand why should package/inherit be called package/replace, it doesn't replace anything. What it does is that it overrides the package fields itself, and also fields of the original replacement of a package. Ensuring that if there is a graft, package/inherit overriden fields will also affect that graft. If you use (package (inherit )), the replacement would stay the same, so your package fields are ignored when there is a new...

<Rutherther>... graft

<bhoot>Oh ok. Loading path via guix build -L ~/my-channel <pkg> should work.

<Rutherther>bhoot: to not pull, why would you pull during development? You can pull as last step to ensure there are no issues like cyclic dependencies between modules somewhere

<bhoot>Rutherther: I agree. I just don't yet have a full mental model of the development cycle. What I had in mind was I would have to guix pull to make the changes in a package definition visible to guix. But what I want is probably `guix build -L`. Then, after things work, guix pull as the last step, as you suggested, in order to test integration.

<Rutherther>yep

<bhoot>thank you, that helped a lot

<apteryx>it looks like we lost the clickable links for commits in Cuirass

<apteryx>e.g., looking at https://ci.guix.gnu.org/build/11974184/details

<apteryx>it looks like we can retrieve a GPG key from codeberg like this: append .gpg to their name, e.g. https://codeberg.org/apteryx.gpg

<apteryx>neat!

<jmes>Anyone know if ungoogled-chromium will be bumped any time soon? Upstream is at version 138 and we're at 112

<jmes>Or perhaps there a reason not to upgrade

<jmes>there is*

<futurile>jmes: AFAIK there's no reason "not to" upgrade, it's because there's no-one to do the work. I think there was a discussion on guix-devel recently about it - suggesting that it be removed if no-one steps up I think

<jmes>futurile: Good to know, thanks! The package definition looks a bit involved for me to do myself

<futurile>jmes: yeah I think everyone's in the same boat

<untrusem>I have two channels that provide emacs package, but the guix is installing emacs from the unofficial channel, I want it to use official channel, is there an option to specify this?

<csantosb>Morning Guix ! I'm afraid we still have a lot to do regarding communication ... https://github.com/parallaxsw/OpenSTA/pull/266#issuecomment-3067406211

<untrusem>we are so underrated

<sneek>Welcome back ekaitz :D

<ekaitz>sneek: botsnack

<sneek>:)

<ekaitz>this bot loves me again

<futurile>untrusem: I don't think there is a way to specify which package you get when you have multiple channels with the same variable in them.

<untrusem>Aah I see

<jlicht>hello one and all

<futurile>morning jlicht

<csantosb>untrusem: I might be wrong, but probably the first in $GUIX_PACKAGE_PATH is the one you'll get, with a message warning you about the duplicity

<untrusem>I don't have that env variable in my shell

<csantosb>What about altering the order of channels in channels.scm ?

<untrusem>ok let me test that

<untrusem>though guix in on top

<untrusem>lemme try switching it bottom

<andreas-e>Are the two packages at the same version? Otherwise you could just install one of them as emacs@x.y.z.

<untrusem>yep they are at same version

<untrusem>csantosb, changing order doesn't seem to have any effect

<andreas-e>A random one would be chosen.

<andreas-e>At least I think so. Maybe it is not random, but no guarantee is given.

<andreas-e>I think that channels should not redefine packages in Guix; maybe negotiate with the channel authors? It would be enough to give the package a different name.

<untrusem>I think there should be an option to specify packages or channels preferences

<Rutherther>untrusem: not with specifications. Just refer to it via the module + variable expresion in guile

<untrusem>can you give an example?

<Rutherther>"guix package -e="(@ (gnu packages emacs) emacs)"" as an example to install emacs from guix

<untrusem>ohh, for home, I have to define it in the home-config

<Rutherther>sure, then just import the module and use the emacs symbol rather than using specifications

<adanska>for a package that needs another gcc ie `gcc-toolchain@13`, how do i import it without breaking everything? `commencement` just wrecks everything

<identity>adanska: you might want to patch it to work with default gcc-toolchain if that is possible

<adanska>identity, that would be impractical for this project, it uses c++20 features

<adanska>okay i added gcc-13 to the inputs instead... doesnt seem to be breaking anything

<identity>adanska: then you might want to use package-with-c-toolchain (i think?)

<adanska>identity, thats only a command line package transformation option i think, adding gcc-13 to the native inputs worked :)

<identity>adanska: "Procedure: package-with-c-toolchain package toolchain" in (info "(guix) package Reference")

<PotentialUser-49>Hi all. I'm creating a guix package. The source requires two sequential makes, first make -C <dir1>, then make -C <dir2>. Does anyone have any suggestions how to do that?

<identity>PotentialUser-49: add build phases that do that?

<andreas-e>adanska: You might also wish to wait until core-packages-team is merged. I hope we will arrive there in a few days, but it also depends on whether we will discover new problems.

<andreas-e>This will compile with gcc@14 by default. So a good test would be to already use gcc@14 instead of gcc@13.

<Kolev>daviid, have you thought of making a graphical Adwaita installer for Guix?

<PotentialUser-49>identity, I understand how to add build-phases, but not how to add multiple of the same. Do you have any links?

<adanska>andreas-e, cool! I've send the patch already as #1229, but when it drops i will switch to gcc@14. iirc it works with 14 but upstreams builds with 13 so i just kept it there.

<adanska>looking forward to the branch merge though!!!

<andreas-e>PotentialUser-49: You can simply add a phase after 'build that does something like (invoke "make" "-C" "DIR2") (exact syntax to be copy-pasted from an example in the code)

<identity>PotentialUser-49: what do you mean "multiple of the same"? just add multiple phases for every subdir...

<andreas-e>Or replace 'build by a phase that invokes "make" twice; no need for two phases if they immediately follow each other.

<ekaitz>PotentialUser-49: or replace the build phase with a (for-each (lambda (d) (chdir d) (invoke "make")) list-of-directories)

<PotentialUser-49>andreas-e identity ekaitz, that makes sense, thank you, I'll give it a try

<andreas-e>ekaitz, PotentialUser-49: (chdir d)(invoke "make") may not work, since it is missing the (chdir "..") at the end. Use with-directory-excursion.

<ekaitz>oh yeah sure I was just writing it from the top of my head

<PotentialUser-49>andreas-e, which is preferable, multiple (invoke "make" "-C" "dir"), or with-directory-excursion?

<PotentialUser-49>Also, will invoke inherit #:make-flags?

<ekaitz>it depends on the case, how many directories do you have?

<PotentialUser-49>ekaitz, just two. The first just wants a make, the second a make, make install

<ekaitz>if it's just two you could copy them

<ekaitz>whatever that feels easier to read foryou

<PotentialUser-49>ekaitz, with you. Do you know if it's possible to have the (invoke) inherit #:make-flags?

<ekaitz>that's a very interesting question

<ekaitz>PotentialUser-49: look at the netdde package

<ekaitz>the make-flags are inserted in the build phase as arguments

<ekaitz>you can just take them if you want

<ekaitz>the same way the `gnu-build-system` does

<identity>PotentialUser-49: (lambda* (#:key (make-flags '()) #:allow-other-keys) (apply invoke "make" make-flags))

<ekaitz>identity: nooooo! let him read! :))

<ekaitz>him/her/them

<PotentialUser-49>ekaitz identity thanks very much. I'll read, I promise!

<ekaitz>PotentialUser-49: i'm just trying to encourage you to read the guix codebase to make you become a long term contributor

<identity>that lambda does not handle parallel-build?, so you know where to look

<PotentialUser-49>ekaitz, oh I understand. For my day job I'm a developer on a certain Corp Linux Distro that will go unnamed, but I very much do the same thing :D

<ekaitz>PotentialUser-49: the build phases in `guix/build/gnu-build-system.scm` (or any other) are like the ones you write yourself

<PotentialUser-49>This is my first time with both scheme and guix, but I'm trying to package some Z80 cp/m development tools. Once I have them vaguely acceptable, I'll submit them

<ekaitz>PotentialUser-49: sdcc or such?

<PotentialUser-49>ekaitz, zasm assembler, sjasmplus assembler, and z80pack emulator

<ekaitz>oh great

<PotentialUser-49>sdcc is great, but a bit overkill for just hacking on a homebrew z80 system

<identity>PotentialUser-49: you can submit a WIP pull request on codeberg with whatever you have now and somebody should help with bringing it to a merge-able state

<PotentialUser-49>identity, super will do!

<z572>andreas-e: maybe we can add a pin issues on codeberg.org, for call on everyone to use core-packages-team.

<dariqq>is there something special I need to do get powerpc64le emulation working with qemu-binfmt? I have added the platform in the service but it fails to execute the build guile driver with ENOENT

<andreas-e>z572: Good idea!

<andreas-e>QA is still working on it; for my profile there are ungoogled-chromium and libreoffice that need to be built.

<andreas-e>We are at 85% on x86_64, compared to 95% on master, so I suppose all will be built in about a day.

<gabber>is it a known issue that the link referred to in section 22.14.1 (Applying for Commit Access), i.e. https://codeberg.org/guix/guix/settings/collaboration does not work? i guess it does for people who can access our codeberg repo's settings page, but for the issue at hand this is somewhat useless. has there been some discussion of the issue already?

<z572>andreas-e: libreoffice is built for me.

<andreas-e>gabber: It is a link that is probably only visible to committers. I see a list of people and a list of teams there.

<andreas-e>z572: Good! I do not mean it does not build, it is just not available on QA right now, and I did not want to spend time and disk space building it. But it is good to know it will not be a blocker.

<andreas-e>Did anybody build ungoogled-chromium from core-packages-team? Anyway I suppose this is not merge critical anymore.

<dariqq>answering my own question i had the name of the qemu-platform as "powerpc64le" instead of "ppc64le" and the 'lookup-qemu-platforms' procedure silently dropped it argh

<z572>andreas-e: i think is only owners can see, I can't see.

<andreas-e>Ah indeed. We have 12 owners and 29 more collaborators.

<andreas-e>Soone one more :)

<gabber>andreas-e: and that is exactly the problem, for this link is there to hint people thinking about applying for commit access to find people who already have it

<gabber>andreas-e: yay \o/

<gabber>so this issue has not been discussed yet (on guix-help or guix-devel)?

<gabber>guess i'll craft an email, then

<andreas-e>I seem to recall that it was mentioned, but do not know where. How about opening an issue?

<andreas-e>In a sense we need the list so that people who want commit access can look for sponsors. On the other hand they should also have interacted with committers and know some of them, so I am not sure it really is a problem.

<andreas-e>And there is also "git log".

<andreas-e>git log|grep Signed-off|sort|uniq

<andreas-e>git log|grep Signed-off|sort|uniq -c|sort -n

<z572>i think is https://codeberg.org/guix/guix/issues/13

<gabber>z572: thanks!

<gabber>guess i'll craft a patch then (:

<andreas-e>Indeed! The members are at https://codeberg.org/org/guix/members

<z572>andreas-e: should we need wait core-packages-team's armhf-linux and i686-linux substitutes?

<andreas-e>armhf, I would say no. i686, maybe, I do not know.

<andreas-e>i686 on QA may take too long for us waiting. It would be good if CI were repaired.

<z572>Can anyone access ci and fix this issue?

<andreas-e>I think there are not many people who know cuirass, so the fixing part is the problem. civodul, rekado or mothacehe I think.

<z572>maybe can send a mail to guix-sysadmin@gnu.org ?

<andreas-e>Maybe; I mentioned it in a mail on the core-packages-team merge request, so people should be aware of it.

<csantosb>gabber: there is also guix/.guix-authorizations

<csantosb>Which gives 45

<csantosb>And 44 members. Someone is missing here ...

<andreas-e>Maybe someone has not asked for an account on codeberg.

<Rutherther>if anyone could give feedback to this: https://issues.guix.gnu.org/78179, I would be very happy :D

<z572>andreas-e: https://codeberg.org/guix/guix/issues/1234

<andreas-e>Excellent! I rather hope we can merge core-packages-team this week :)

<andreas-e>I had a look at your adb fix. I suppose you tried to do only one of the header or gcc@11 addition?

<z572>because the default linux-headers is updated.

<z572>so need add linux-headers@5 and gcc@11

<andreas-e>I confirm, having tried with only one or only the other, and also gcc-13 and gcc-12. Annoying!

<ekaitz>anyone wants to help me update neovim?

<andreas-e>Now its dependent, fastboot, fails; but I think it can be solved by adding a "Wno-error" flag.

<andreas-e>ekaitz: I use old vim, but wondered what else was done around neovim, using this search: https://issues.guix.gnu.org/search?query=neovim&is=open&package=guix

<andreas-e>In particular https://issues.guix.gnu.org/48112 could make use of your comments :)

<ekaitz>oh very old stuff there

<dariqq>ekaitz: afaik it is updated on rust-team branch

<ekaitz>andreas-e: that one could be just merged

<ekaitz>dariqq: but why only there? :(

<andreas-e>ekaitz: Can you merge it then?

<andreas-e>Sesrching for neovim on codeberg shows that 0.11.1 is already on the rust-team branch.

<ekaitz>andreas-e: I'll make sure it's ok and yes, probably merge

<andreas-e>This is in line to be merged.

<ekaitz>11.3 was released a couple of days ago

<andreas-e>Thanks, ekaitz!

<Rutherther>ekaitz: could you clarify, do you mean rust-team could be merged completely, or only neovim updates?

<andreas-e>Okay. So you should probably base your work on the rust-team branch.

<ekaitz>but why is it only updated in rust-team?

<ekaitz>isn't that weird?

<andreas-e>I do not know. Is it written in rust?

<Rutherther>because a lot of dependencies had to be updated

<Rutherther>and those were updated on rust-team

<Rutherther>I believe they are rust dependencies, but I would have to check to confirm that

<andreas-e>It is all a bit strange. I think it is written in C with a number of lua inputs.

<ekaitz>i just compiled it with 2 dependencies being changed

<ekaitz>tree-sitter and utf8proc

<ekaitz>both are C dependencies

<Rutherther>but when you update tree-sitter, don't you also have to update the grammars?

<futurile>tree-sitter has rust stuff doesn't it?

<ekaitz>it might, but just updating the version worked idk

<Rutherther>did you try compiling all the grammars though?

<Rutherther>(or rather all referrers of tree-sitter)

<ekaitz>no i didn't that's why I asked for help

<ekaitz>and if it's in rust-team and it's almost merged, I'll just leave it

<ekaitz>it's like the rust-team branch is going to eat all the development in the future

<ekaitz>the cargo effect

<futurile>andreas-e: so what's the situation with merging core-packages-team - I guess qa is borked, but you can see build status?

<Rutherther>ekaitz: see https://issues.guix.gnu.org/70146, some grammars have to be updated so that they build

<Rutherther>updating tree-sitter is really not that easy as just updating the base package, unfortunately

<ekaitz>heh

<ekaitz>uh holy shit

<Rutherther>but it's unfortunate that there don't really seem to be any updates about merging rust-team, maybe I just missed them

<andreas-e>futurile: QA has picked up, either because cbaines has worked on it, or maybe it has just fallen into working, as the French saying goes. See here:

<Rutherther>the branch isn't even in the qa queue

<andreas-e> https://qa.guix.gnu.org/branch/core-packages-team

<ekaitz>andreas-e: i'm not sure about using native-search-path in the patch you sent me

<Rutherther>oh wait it is, my bad

<Rutherther>it appeared in the last day

<ekaitz>isn't search-path better there?

<andreas-e>ekaitz: I have no idea, that is why I asked :) I do not think I have ever encountered native-search-path.

<ekaitz>gcc has them hehe

<andreas-e>I suppose it would be used when neovim is in native-inputs? This does not look like a likely situation.

<ekaitz>yeah...

<Rutherther>when one wants to become member of a team, is putting real name to teams.scm a requirement?

<ekaitz>Rutherther: i think unmatched-paren doesn't use their name

<ekaitz>so, no

<ekaitz>andreas-e: i guess they are trying to set that for the plugin directory and such

<Rutherther>ekaitz: great, thanks!

<ekaitz>but idk if native-search-paths is the proper way for that

<Rutherther>andreas-e: on the contrary, it being a 'native-input' is very common, as you use it very often in a profile via guix install etc.

<andreas-e>ekaitz: I have looked it up here: https://guix.gnu.org/manual/devel/en/html_node/Search-Paths.html

<andreas-e>But why native? What is the cross compilation context here?

<ekaitz>exactly, that's what I don't see

<andreas-e>I think a simple search path will work.

<ekaitz>i agree

<ekaitz>because even when you cross compile it, it should be able to load the plugins of the host machine

<futurile>I think there was an update on merging rust-team, I saw something fly past - but I can't find it now <sigh>

<andreas-e>rust-team is in the QA queue.

<ekaitz>it should also have the XDG_CONFIG_DIRS

<andreas-e>Hello civodul!

<andreas-e>We wondered with z572 about i686 - should we wait for it before merging core-packages-team?

<ekaitz>i don't see any proper use of search-paths... i only find native-search-paths

<andreas-e>Right now the build queue for x86_64 is drying up, we are almost through.

<Rutherther>ekaitz: search-paths are used for cross compilation, like for CROSS_C_INCLUDE_PATH, the cross-gcc has them

<ekaitz>Rutherther: so we should use the native- case?

<ekaitz>this is not clear

<Rutherther>futurile: there is a new issue 'request for merging...' for the rust-team branch, I suppose that is the update you mean

<futurile>Rutherther: ah ok, that must be it

<Rutherther>ekaitz: yes, I believe native-search-path should be used, because you care about the search path when neovim is in the profile 'natively' for the architecture the profile is for. At least if I understand properly that the search path is for end users, not for compilation of packages that have neovim in inputs

<Rutherther>ekaitz: note that there is $XDG_DATA_DIRS variable in (guix search-paths), so it might be better to use that rather than to specify it

<Rutherther>and generally... xdg data dirs is a search path needed for a lot of packages, and as far as I know, Guix hasn't really decided on a good way to handle it. There is very very old issue discussing search paths and their propagation

<ekaitz>yeah... now I'm wondering... why does neovim work atm?

<ekaitz>we even have packages for it

<Rutherther>because both Guix system and Guix home solve this issue without search paths, they sidestep them and just export them in /etc/profile

<cbaines>Rutherther, I'm not sure you're right about search paths, see https://guix.gnu.org/manual/en/html_node/package-Reference.html

<cbaines>although I'm also confused about the use of "host" in the documentation

<ekaitz>me too! that's why I thought search-paths would be better

<Rutherther>cbaines: so what part do you think conflicts with what I said? Because I don't see it

<ekaitz>but in the end, there's almost no package in the whole codebase that uses search-paths

<cbaines>Rutherther, this bit "profile 'natively' for the architecture the profile is for", that would be the search path, not the native search path, because the native neovim would be from the system you're doing the build on, not necessarily the system the profile is for

<Rutherther>ekaitz: neovim packages might won't work in guix shell because of that though. If they do, then it means neovim can somehow still find them even without xdg data dirs

<ekaitz>hm

<ekaitz>they would work in a shell that doesn't change the env

<ekaitz>and could be loaded from a shell if the package has also the search path

<Rutherther>cbaines: right, I put the natively in quotes for this reason, it is not very clear in that regard, but I believe native-search-paths actually means search paths for the architecture of the profile

<Rutherther>cbaines: as a prove of my point, see this example: https://paste.debian.net/1385880/ bash has native-search-paths and they are in the profile

<gabber>z572: should i tell you here which packages failed to build or should i comment in the issue?

<andreas-e>gabber: I think the issue would be most helpful. Better yet, a PR :)

<ekaitz>okay I don't know what to do with the patch so i'll just leave it

<ekaitz>after 4 years I don't think it'll matter

<Rutherther>cbaines: native in native-search-paths in regards to profile means native to the platform the profile runs on, it is not related to the compilation environment

<ekaitz>i'd say the docs have to be improved in that, because that's not what I understand from them

<Rutherther>ekaitz: yeah, I also didn't understand it from them and understood it only when I wrote a tool for cross shells where I had to dig into how they actually work

<cbaines>Rutherther, I'm assuming this is consistent with inputs/native-inputs for packages, and if it's different, then I am confused

<Rutherther>cbaines: if you are compiling, yes, I believe it will be consistent with inputs/native-inputs. And search-paths is also going to be taken from target-inputs, but those aren't exposed to packages, they are only in bag

<z572>gabber: please open a issue, other people also can try fix it. or a PR to fix it :)

<andreas-e>z572: I just pushed core-packages-team, but forgot to rebase. I will leave it as is for now.

<andreas-e>binutils-gold is important, as it will unlock a lot of builds for the ARM architecture.

<andreas-e>z572: When I look here (thanks cbaines for explaining things to me!): https://data.qa.guix.gnu.org/build-server/2/build?build_server_build_id=d4d42efc-5a05-4169-ad22-ee1a7d8245bc

<andreas-e>I see that libreoffice fails to build on QA since glib-networking and ruby-mysql fail.

<andreas-e>Could you build these locally?

<andreas-e>I get the first one, but not the second one.

<z572>glib-networking is successful,ruby-mysql2 is fail.

<andreas-e>ruby-mysql2 looks like the usual "Wno-error=" stuff. Maybe I can simply push a fix.

<z572>but i think ruby-mysql2 is not libreoffice's inputs

<andreas-e>Maybe it is just somewhere on the paths of inputs of inputs and so on.

<andreas-e>Just updating it from 0.5.2 to 0.5.6 is enough.

<luca>rust-team in master :O

<luca>sorry, i scrolled

<gabber>do we have some build environment where uint64_t is *not* defined? why would a package suddenly fail like this?

<gabber>*package build

<Rutherther>gabber: on master branch or on core packages branch?

<gabber>core-packages-team, the failing package is crossguid

<andreas-e>It is in some header file, I think stdint.h.

<Rutherther>okay, then it is because of updated gcc

<z572>gabber: gcc 13 tightened the requirements.

<Rutherther>it seems the previous gcc was including this header automatically somehow, now stdint.h has to be added

<gabber>hmmm. and they threw out stdint.h?

<andreas-e>Sometimes these were recursively imported by other header files before and now not any more.

<gabber>i see

<andreas-e>So one could argue that it was an error in the C code of a package, but that could not be noticed.

<gabber>at least a patch seems relatively easy ;)

<z572>c lacks namespaces :(

<identity>headers should not include headers, fixes half of your problems

<gabber>identity: how would you then declare stuff like uint64_t in a header in C?

<identity>gabber: well, you would tell people to include the headers your header depends on, or did misunderstand the question?

<gabber>identity: in the case at hand (where functions make use of c standard types) it is necessary that the headers declaring these functions include the (c standard type) headers - so at least in that case headers need to include headers. but i guess i misunderstood your previous statement?

<andreas-e>All -P1 dependents of ruby-mysql2 build on x86_64, so I have pushed the update to master. It will end up in core-updates after the next rebase, which I could do tonight.

<identity>gabber: if you write "this header depends on stdint.h" in the manual page for the header, and people will #include both stdint.h itself and your header that needs stdint.h, it should work alright without cpp trying to #include stdint.h 50 times over, or code breaking because some header no longer #includes stdint.h

<identity>cpp as in C Pre-Processor if that was not clear

<bvd>Is there a way to get Rust 2024?

<identity>bvd: the rust-team branch probably has it, but you could use rustup in a(n) FHS container

<untrusem>cargo install don't work usually in guix

<untrusem>I didn't tried in a fhs shell maybe I should

<bvd>identity: I don't see rustup in Guix main channel.

<bvd>Unless it's rust-rustup-toolchain, but that's version 0.1.6

<identity>bvd: just get it from the official website

<bvd>I suppose like this then https://www.reddit.com/r/GUIX/comments/11hwqu6/how_to_do_rust_development_on_gnu_guix/

<futurile>bvd: yeah a few people do "development using Rust" under Guix - it's generally going to be better to use the Rust native tools. A quick search should turn up some blog posts

<bvd>identity: Thanks, looks like it can work.

<bvd>futurile: So yeah that is also my impression but I would prefer a "stable" version that still works on Guix's toolchain instead, even if containerized.

<RavenJoad>I want to thank whomever made the modular texlive-scheme-full package collection fast agin. I pulled in the middle of June and just recompiled some documents and compile time went down from minutes to seconds!

<untrusem>you can use git blame and see who did that and send them a thank you mail

<untrusem>😌

<bvd>I'm getting permission errors on /tmp, that doesn't make sense, my /tmp is 777... guix shell: error: mount: mount "none" on "/tmp/guix-directory.....": Permission denied

<civodul>bvd: this is from ‘guix shell -C’, right? are you on Ubuntu?

<gabber>sooo, i've created a patch that builds crossguid - should i still open an issue or can i send it to someone directly via mail? z572? andreas-e?

<ieure>gabber, Send a PR.

<ieure>s/send/open/

<bvd>civodul: Ubuntu, yes.

<getstate>How does one get QT to respect your theme if you're on a window manager? I tried settings `QT_QPA_PLATFORMTHEME=qt6ct`, but only qt6ct respects it?

<andreas-e>RavenJoad: You have most probably ngz to thank!

<untrusem>ohh themes in guix my be loathed

<getstate>I mean all the QT based apps are missing icons for me ;_;

<aitzkora>Is it possible that a package defines an environment variable that could be used when one loads the package ?

<luca>like a wrapper?

<ieure>aitzkora, Yes, with a wrapper script.

<ieure>Many do this.

<bvd>civodul: Do I have to disable AppArmor?

<aitzkora> ieure: have you an example in a guix recipe ? In fact, I have a python module which depends on a dynamic library store in an environment variable

<ieure>aitzkora, Search "wrapper" in gnu/packages in the Guix code.

<andreas-e>gabber: In #1238, your substitution that starts on the new line looks ugly since it collides with indentation. Could you check whether using \n in the substituting string works? Or something similar. At worst, a (string-append.

<csantosb>aitzkora: maybe you refer to "native-search-paths" and "search-path-specification"

<csantosb>See for example: https://codeberg.org/guix/guix/src/master/gnu/packages/perl.scm#L267

<getstate>Ah, think I figured it out...

<aitzkora>csantosb: I was not aware to that field of package : the name make me thinking that its aims is for building a package (native) but I will give a try

<csantosb>aitzkora: just don't abuse of its use, and take it as a last resource; privilege using a wrapper, when possible

<vagrantc>so, diffoscope is basically all python, but is under team-reproduciblebuilds ... but i am the only member of the reproduciblebuilds team ... is it ok to ping team-python in a pull request?

<vagrantc>basically with diffoscope, most of the time i submit a request and wait 7 days and then push it ...

<vagrantc>*sometimes* other folks notice and push it first

<andreas-e>I think this falls under the "trivial update" policy, and you can push immediately; I suppose there are no dependent packages?

<futurile>Q: in the a2ps (pretty-print.scm) package there's a call to substitute* 'rm' using 'which rm'. I know where the which function is coming from, but where is 'rm' coming from? I don't see an input of 'coreutils'

<futurile>(I'm writing a blog post on handling references and now my example is confusing me heh)

<ieure>futurile, rm is part of coreutils, isn't it?

<ieure>futurile, Oh, rereading your Q.

<ieure>futurile, I think coreutils is an implicit input from the build-system.

<ieure>futurile, Concretely, (guix build-system gnu) has a `standard-packages' procedure which returns the set of packages implicitly in the build environment. That reuses %final-inputs from (gnu packages commencement), which has coreutils (and a bunch of other stuff).

<futurile>ieure: ah brilliant - thanks that's what I was finding =-)

<futurile>wasn't even

<dodoyada>hello! anybody run local llms (compatible with emacs-gptel) on guix? I know I could set them up using guix containers; I'm just wondering if there's any particularly low friction way to set one up to try out

<PotentialUser-39>hi

<ieure>Hello.

<bavier>hi PotentialUser-39

<PotentialUser-39>first time irc actually lol

<bavier>yay \o/

<ieure>Welcome! Don't paste a bunch of stuff in. :)

<ieure>A thing newcomers tend to do.

<PotentialUser-39>i want to have more confidence on guix compared to nixos

<PotentialUser-39>do you guys think nixos bloated and inflated?

<ieure>Never used NixOS, have no opinion on it.

<ieure>I assume it's disk-hungry, as Guix is.

<dodoyada>never used nix, I assume it has immensely more packages but worse configuration vs guix

<andreas-e>If you are here for the first time, does it mean that all PotentialUser-XY are actually different? Is it a particular client that imposes such a nickname?

<bavier>andreas-e: I believe the web interface linked at guix.gnu.org defaults to the PotentialUser-N nick

<PotentialUser-39>uh well... i just installed guix and joined here first time for feeling irc vibe

<ieure>Correct.

<ieure>andreas-e, It's from https://guix.gnu.org/en/contact/irc/

<PotentialUser-39>correct, that link

<ieure> Which redirects to https://web.libera.chat/?nick=PotentialUser-?#guix

<andreas-e>Ah, interesting, I thought it was just one person :) Lots of discussions with potential users then.

<untrusem>nix helped me in setting up php dev env, guix is newer than nix so fair

<ieure>andreas-e, The way the numbers work mean that different users can have the same nick, and the same user can have a different one. Wheeeee

<dodoyada>PotentialUser-39 quick tip, `guix search package-name` is always way faster than the web ui

<andreas-e>It looks like ?#guix is a random number generator. Weird.

<untrusem>the only advantage I think nix has, the packages and utilities around those packages

<PotentialUser-39>i first thought guix is more focused on foss but as i start using nonguix, the difference between guix and nixos became vague

<ieure>andreas-e, It picks some unused number.

<ieure>PotentialUser-39, nonguix != guix, it's an unofficial addon. Guix itself only contains Free Software which can be built from source.

<dariqq>argh qtdeclarative ooms on i686 during 'make-dynamic-linker-cache

<PotentialUser-39>yeah i think that's cool. it's a valid feature rather than being mere limitation or disadvantage

<dariqq>the amount of workarounds i have to do keeps getting bigger and bigger :/

<ieure>PotentialUser-39, Guix uses Scheme for system configuration and to create packages. Again, haven't used Nix, but having looked at how they do that stuff... I like the Guix approach much better.

<PotentialUser-39>nixos requires allownonfree option on, but it makes user use nonfree software too easily

<identity>PotentialUser-39: the main difference is the interface i would argue, not only does Guix use Scheme, but also the cli is very different

<PotentialUser-39>i think guix is more focused on core things. nixos tries to cover too many packages. i even suspect if that's maintainable for package servers

<untrusem>also it is tied to github

<PotentialUser-39>i once used nix, and the usage is quite similar, but i feel better while i use guix cli

<untrusem>github bad

<PotentialUser-39>what, nixos? is it tied to github?

<untrusem>yep, in a way, nixos, all the projects around it uses github

<PotentialUser-39>btw it feels better when it's backed by gnu, rather than nix foundation lol

<untrusem>exactly, I don't want to ping github a thousand times a day 😛

<PotentialUser-39>and i think there's also difference between the community. guix community is more sincere. meanwhile nixos brings too many hassles

<untrusem>can't comment, never been part of nix os community

<untrusem>guix is all I need 😌

<PotentialUser-39>true lol guix so best

<PotentialUser-39>unbelievably

<PotentialUser-39>what i mean is, since nixos tries to cover too many packages, there so so many people who just focus on using new experimental features, rather than focusing on actual problems

<PotentialUser-39>but with guix, i can focus more on actual issues, rather than wasting time on untested experimental features

<PotentialUser-39>actually, i once thought guix like meme os lol

<PotentialUser-39>'no wifi firmware? wtf?'

<PotentialUser-39>i felt like this

<dodoyada>to be fair, guix is pretty demanding in terms of personal effort for any unusual cirumstance but if that's you, you're me

<untrusem>but guix is `do it yourself` os currently

<PotentialUser-39>i once thought the free software like meme

<PotentialUser-39>but actually, i think guix makes sense

<PotentialUser-39>free software spirit made me think on myself

<PotentialUser-39>rather than hoping os maintainers do better

<PotentialUser-39>i stopped my distro hopping

<untrusem>you can use usb thethering while in libre kernel to do stuff

<PotentialUser-39>infinite thanks to gnu team and guix os

<PotentialUser-39>also i started reading documentation lol

<PotentialUser-39>i always tried to find some community qna

<PotentialUser-39>guix fixed my so many wrong attitudes

<PotentialUser-39>just some confession

<untrusem>😌 glad for you

<PotentialUser-39>most of all, guix made me find irc channel for the first time of my life

<PotentialUser-39>im currently listening to hacknet ost, and it makes me feel like a decent hacker lol

<PotentialUser-39>i recommend hacknet ost

<PotentialUser-39>it's so good

<PotentialUser-39>hacknet is some hacker-vibe game like linux

<PotentialUser-39>most linux users will like it

<PotentialUser-39>honestly, i hope so bad for guix to spread more widely

<PotentialUser-39>i want it to be standard os for most users (at least for linux users)

<PotentialUser-39>do you think if there is any chance?

<PotentialUser-39>or is it just my too big dream?

<PotentialUser-39>i think guix has potential

<PotentialUser-39>it's truly amazing os

<PotentialUser-39>hello?

<PotentialUser-39>anyone here?

<ekaitz>PotentialUser-39: there's people here

<PotentialUser-39>so quite lol

<ekaitz>it's quiet now, but it's not so quiet normally

<bavier>yeah, people respond when they feel like it

<PotentialUser-39>would guix be more popular?

<PotentialUser-39>i hope guix be more popular

<PotentialUser-39>the philosophy, and the approaches are so good

<PotentialUser-39>but it's sad cuz i felt guix community relatively smaller compared to others

<luca>ref usb tethering I have a kind of funny story. I was once running linux libre with USB tethering to my googled android for wifi. Then I installed lineage OS with no wifi drivers on my phone, so I had to switch to non-libre linux to USB tether wifi from my computer to my phone

<luca>Really just a ton of mistakes on my part and also the industry for not providing free wifi drivers. But oh welp

<futurile>luca: gah, so much time spent trying to figure out stuff like that!

<ieure>luca, When I first put deGoogled Android on my phone, I accidentally installed the Pixel 3a XL image instead of the Pixel 3a one. It booted, but the controls to get through the first-run stuff were off screen, because it assumed a different display than what I had. Oops.

<ieure>luca, I plugged a keyboard/mouse into a USB hub, USB hub into a USB A->C adapter, adapter into the phone, and keyboarded my way through stuff to reenable OEM unlocking so I could reflash the right image.

<postroutine>If someone have already deployed Prosody and a XMPP gateway on Guix System: Did you find a way to set the server to gateway secret without needing to encrypt the entier XMPP server and gateway config files ?

<postroutine>I know guix-sops could be used to encrypt a secret to use it on a Guix System config, but it require to encrypt a file. And Prosody don't let you set an external component secret via a file.

<nomike>I'm working on a few packages and package updates. For that I have cloned the guix repository and I'm editing definitions directly in the clone. I'm also using guix-home. Is there a way to put a package definition into my guix-home config, so that it can be copy/oasted between guix-home and guix without having to modify it?

<futurile>nomike: create a packages module I guess: I have a folder under my guix home location called 'packages' and have some custom packages in there.

<futurile>nomike: then you could copy-n-paste the definition into your new module; load it in your guix-home config; install them etc

<ieure>nomike, I generally test packages with `./pre-inst-env guix shell ...'. Doesn't work if you're testing services, or have stuff that needs to be in a profile, but works fine for most cases.

<futurile>postroutine: can you read the 'secret' into a env-variable somehow, then pass that to prosody

<postroutine>futurile: Can I choose the user that the env-variable apply to ?

<postroutine>Ho, in a Prosody config file, I can call "FileLine()" as an option value to read a one line file and use its content as the option value.

IRC channel logs

2025-07-14.log