IRC channel logs
2026-01-27.log
back to list of logs
<old>Is there support for BASH_COMPLETION_USER_DIR? I have a package that install some bash completion script in share/bash-completion and would like the environment variable to be updated upon entering a guix-shell. Kind of like MANPATH does <mange>It looks like our Bash will read BASH_COMPLETION_USER_DIR, but Guix won't set it. We'd need to add a search path to bash if we wanted that. (Looking at bash-completion-directories.patch it seems we just hard-code some profiles instead of using a search path - I don't know why.) <nckx>This is the second time I'm about to report babbies first Codeberg issue and that Codeberg is down. <mange>Is it possible that you're the one bringing Codeberg down? <nckx>We do both have a lot of issues. <mange>nckx: Codeberg seems to be back up, if you want to give it a go again. <Ironsmith>hey team! is there a strict styling guide for how to include (inputs) and which order the (inputs) appear in the package definition? <Ironsmith>i usually do (source) (inputs) (arguments) ... because that makes more sense to me, usually you declare inputs first, also in (inputs) you can have items that are defined via (origin) so i find (source) and (inputs) are strongly linked <Ironsmith>and i thought as long as it was well thought, and not overtly distracting, there's no issue with these kinds of variations <Ironsmith>however i'm getting comments on one of my PRs indicating otherwise <Ironsmith>actually a lot of strange comments from this user <Ironsmith>one which is pretty offensive, accusing me of just dumping LLM output <mange>I'll have a look at the PR, but my first thought is "what does guix style do?" <Ironsmith>thanks mange! interesting i never heard of or used guix style. but is it a requirement? the PR template only mentions running guix lint which i do for every PR <mange>I don't know if it's a requirement, but if there's contention over code style I would say whoever's closest to "guix style" wins. In particular, you're breaking a cardinal rule of indentation: subforms should all end up to the right of the list they're in. Your (inputs (list ...)) where the listed inputs are less indented than the "list" term make me uncomfortable. :) <mange>Similarly, the rule with "let" is always "the bindings start on the same line as the let, and the body is indented two spaces below". <mange>FWIW, I also agree that the modification you're doing in a phase should be a patch. <Ironsmith>interesting, thanks mange i didn't realise that was a cardinal rule <Ironsmith>you run out of horizontal space really fast that way though, and it looks so ugly <mange>Consistency has a beauty of its own. :) <Ironsmith>is there a best practice for what determines what should be in a patch and what can stay in the package definition? <mange>But yes, you do run out of horizontal space very quickly. Especially with long names. <mange>In general, I would say: use a patch for changes that don't need to reference other packages/outputs. There are always exceptions, but that's my usual default. <mange>In my mind it's "patches for changes; snippets to remove vendored code, nonfree bits, or precompiled binaries; phases for patching in store references". <RavenJoad>Hey, real quick. Is asymptote supposed to install its LaTeX package into texmf or texmf-dist? My texlive-scheme-full cannot see asymptote's package because the asymptote package puts the .sty file in texmf. <RavenJoad>Guix puts the modular texlive-* packages in texmf-dist. So I was wondering why asymptote is having their's put in texmf. Guix is making that specification with #:configure-flags. So I'm building the monolitic texlive package to see if that is the reason. <RavenJoad>After investigation, it seems that the only reason asymptote is in the wrong spot is that the package was not updated after the texlive -> texlive-* change. The monolithic texlive package includes asymptote in the right spot. <mange>Sounds like an easy fix, then. That's nice! <RavenJoad>mange: Yep. Just build the fix and am testing it now. <flurando>Does anyone has experience getting inputattach-service-type correct? it always says cannot set device type for the /dev/ttyS0 stuff. I am trying to use a wacom cintiq board, what should I do now? <mange>I do not, but the first thing I would check is if your device is detected and /dev/ttyS0 exists. Do you need to load a kernel module or anything? <oliverD>I keep running into guix completely freezing for 10 minutes or so when I have multiple tabs open in tor, is this normal? <flurando>mange: I have removed the service after I found inputattach helps 0 for wacom, which works by default. However, the display does not work, a pity. <flurando>oliverD: Abnormal, but uunderstandable if your device is too lowend. <Minall>I installed inetutils in a non-guix system, yet it doesn't have the inetd, but only the client <Minall>I'm checking at the build and don't see it being disabled, there are a bunch of disables, but only when the target is Hurd. I'm on an Ubuntu in WSL <mroh>Minall: inetutils has inetd and telnetd in /libexec, see "tree $(guix build -q inetutils)". <Minall>mroh: Oh, I see. I went there, made it executable, and it still doesn't run though... <Minall>Perhaps it expects to be ran by xinetd or something <Minall>Alright, I called it with inetd, works perfectly, and even, the vulnerability is not in place? I wonder why? <Minall>Has this package been updated with the mitigation? <- which is good <Minall>How would I check this?. I want to go to a version that has the issue, in order to prove it and archive it (cybersecurity experiment) <futurile>According to (https://nixos.wiki/wiki/Nix_channels) Nix releases an update to users after an update has been built. It means that broken updates don't go to 'master' and that substitutes are always available for an update. Did we try this in Guix, is there a history here? <Minall>Apologies for disconnection, were there any comment about my question <futurile>It seems like it would solve problems for us: something like devs commit to a branch (e.g. main), we build the commit, if it works we automate it to 'master', since it's already built we get the substitutes <futurile>Minall: are you sure you started the Guix 'telnetd' and not the Ubuntu one. Any update to the package would be in the file. <Minall>futurile: Yes, /gnu/store/hwns9ksqpmr1b6qwnj54b8bpm43477y2-inetutils-2.5/libexec/telnetd is the path I am using <Minall>I'm trying to avoid anything ubuntu, since my objective is to prove this vulnerability from my side, with guix <Minall>Though this version should be vulnerable, and if it isn't, I can't find the commit where it was fixed <Minall>As to go previously, and have a lab with and without this vulnerability <Minall>Which btw I found an issue on inetutils that updates it. It is quite simple as I see on the code. I don't know the steps to get the right hash and so on, of course building it. I'll be looking at that later <Minall>Now I first need to understand this vulnerability and be able to reproduce it <futurile>Minall: I don't think it's been fixed. The version I see in Guix is 2.5 and I can see 2.7 on the upstream site <futurile>Minall: you could build the later version locally using a package transformation. <Minall>futurile: Some OSs tend to do backport security fixes. I though this was the case. I can't reproduce it from my side though <futurile>Minall: generally Guix will move upwards, to the latest 'released' version if we can. As we're a rolling release. <Minall>futurile: I'll go to it once I can reproduce it in order to obtain an environemnt without this issue <futurile>Minall: if a security fix isn't available in a released version then yeah it would be patched. When you look at the package definition there's a 'patches' field and that will tell you what's being used <futurile>Minall: the fact that we're on an older version indicates that this package is deep in the dependency tree I guess - so it would cause a whole load of stuff to be rebuilt <Minall>So perhaps I am not reproducing it well, but I don't have much more details on it <csantosb>futurile: A better strategy would be great to have, indeed: team branches, similarly to what we do now, which land on master once built would be enough. Then, a periodical (two month ?) merge to a release branch, with a new tag (2026.02 or so). A real release with artifacts once a year. <csantosb>And while we're at it, a community wiki would help too. <futurile>csantosb: yeah I agree team branches are useful, though I think it's bad when they are slow-moving and merge inoften. But, here I was thinking of the many changes that go directly into our 'rolling' updates. <Minall>I have to test this on another environment, as maybe /usr/bin/login is not being used in the Ubuntu WSL <Minall>So the vulnerability is not triggered, I'll test in an Archlinux with Guix <futurile>csantosb: part of the reason people don't want to merge stuff is because of massive rebuilds. This Nix approach of the users pulling from a different branch to where developers push, seems to solve that. Seems like this must have been tried before and there's some reason we don't do it <Minall>In which case, I would then go with the updated path and have that vulnerability example <futurile>Minall: are you trying to fix this security issue in Guix by contributing a patch? Or just playing/experimenting? <Minall>Both really, since in order to latter have the fixed environment I'd have to update the inetutils package in Guix, and thus have a fixed version. Which requires guix understanding and all <Minall>So I would have a way to always be able to reproduce the issue, and a fixed version in order to experiment and check my tool, mostly experimenting and understanding/playing <Minall>Oh, I would later archive it and be able to guix time-machine it of course, basically a Vulhub but in guix <gabber>noe: what size t-shirt should i order for you? <Kabouik>I can't find the documentation on how to configure clamav on Guix (there is a package but it won't work out of the box). I don't think I really need clamav, but my institutions makes it mandatory to have either WithSecure or HarfangLab as antivirus on Linux machines, and both of them look proprietary and almost impossible to install on Guix (no sources, only binaries that expect systemd, etc.), so I would like to negotiate continuing to use Guix as <Kabouik>long as I use an AV for it. Negotiating with no alternative looks like an uphill battle. <csantosb>"Can't parse clamd configuration file /gnu/store/1mdfl61q7jxc5qfm5phgggd7rx707122-clamav-1.4.3/etc/clamd.conf" <Kabouik>Yes, I think it will require some config.scm work but I can't find any entry for it in the Guix manual <csantosb>`clamconf -g clamd.conf > /tmp/clamd.conf`, modify it, `clamd --config-file=/tmp/clamd.conf` <Kabouik>csantosb: Briefly only, to be honest, I was assuming writing files in /usr and /etc would not be the Guix way and some config.scm snippets and maybe services would be required. I did not spend too much time on it yet (I wasted more time on investigating whether WithSecure or HarfangLab would be possible; and I don't think so). <Rutherther>futurile: could you move the discussion about automatic merges to master somewhere more persistent than here? I would like to comment more. Not now though <futurile>Rutherther: yeah I'll email guix-devel; I'm just worried it's a really stupid question and that the whole group already knows the answer to this heh heh <futurile>Rutherther: normally I ask all my stupid questions at Guix Days and then there's no permanent record of my stupidity/misunderstandings ;-)) <gabber>futurile: lol. i usually do it here. but maybe this year i'll choose your route (: <Rutherther>futurile: :) i have asked this before and the only answer I got is that the tool would have to sign commits and that is not possible since only real people do that. But I think its not an issue, because the bot wouldnt be merging anything, it would just update the target branch by Fast forward. So no signing necessary. <Rutherther>futurile: in my opinion though the way nixpkgs handles this has its issues and I think its important to talk about them <noe>but, how much does it cost? <jeko>I am looking for a snippet of package defnition to tell guix to build from git. and always point to the master branch so each time I build the package it will rebuild from the new commits if any since last build <futurile>gabber: I pass on the 'no question is too obvious to ask at Guix Days' stick to you! :-) <gabber>jeko: i am not sure this is possible within just a package definition <noe>jeko, you can use a with-branch=master package transformation <noe>Without a transformation, you should be able to use `(source (git-checkout (url url) (branch branch) (recursive? recursive?)))` <futurile>I think I got it from a jami repository somewhere <Kabouik>csantosb: I modified the clamd.conf by uncommenting the TCPsocket line which seems to be the main requirement until the next error, but then I'm hitting anotherwall with cl_load() no such file or directory /gnu/path/chare/clamav. I think this means I need to run freshclam to download a database, but this fails with a similar error. <jeko>alright thank you noe and futurile <Kabouik>csantosb: hold on, I'm progressing (slowly). <csantosb>Kabouik: If you hit a wall, please open an issue on codeberg, pinning me, so that I'll be able to react somehow, it would be great to have ClamAV working on guix <Kabouik>I'm downloading the database currently. The vanilla clamav manual is actually useful but I think I need to just work around all the default paths first when generating confs and dbs. Will report back when I'm done (I'm multitasking right now and won't progress fast). <gabber>Kabouik: if you manage to get it working, it would be cool if you could write a small summary of your findings. if not posted anywhere else the help-guix mailing list should be a fitting medium for this <ArneBab>I have a problem with ruby on rails not finding tzinfo ⇒ bin/rails aborted! TZInfo::DataSourceNotFound: tzinfo-data is not present. Please add gem "tzinfo-data" to your Gemfile and run bundle install (TZInfo::DataSourceNotFound) <ArneBab>/home/disy/Dokumente/Wildtierportal/ExtApi/extapi/config/environment.rb:5:in '<main>' ⇒ Caused by: TZInfo::DataSources::ZoneinfoDirectoryNotFound: None of the paths included in TZInfo::DataSources::ZoneinfoDataSource.search_path are valid zoneinfo directories. (TZInfo::DataSources::ZoneinfoDirectoryNotFound) <ArneBab>/home/disy/Dokumente/Wildtierportal/ExtApi/extapi/config/environment.rb:5:in '<main>' <ArneBab>I have ruby-tzinfo and ruby-tzinfo-data installed. <ArneBab>are maybe zoneinfo directories not installed in the expected places? Can I change that? <mange>Are you installing your dependencies entirely using Guix? Or are you using Bundler a bit, too? <mange>I ran into a similar issue, but I can't remember exactly what the solution was. I can hunt around a bit to see what I can find locally. That said, I got fairly annoyed with it all and built https://git.sr.ht/~czan/guix-ruby to do my Ruby dev in Guix. :) <ArneBab>mange: I have a mix of guix packages and bundler … <ArneBab>so maybe I have to *remove* the tzinfo gem? <mange>Well then, I can recommend guix-ruby! It converts Gemfile.lock into a Gemfile.lock.scm which produces Guix packages, so you can use "guix shell" to build your Ruby environment. <mange>If you don't want to use my code, then I think you're best off just installing Ruby with Guix, then using Bundler to install everything else. You might also need gcc-toolchain in your environment (in case you need to compile native extensions). <ArneBab>mange: fixed! Thank you! I removed the gem and installed ruby-tzinfo and ruby-tzinfo-data and made tzinfo-data in the Gemfile unconditional and now it works. <ArneBab>mange: but guix-ruby! sounds interesting. Do you have a tutorial for using it? <ArneBab>I have various local hacks to keep stuff working and having a clean way to get a cruby shell would be great. <xxd>Is the standard Guix System USB install live bootable? I can install but not "try" on the Grub menu <ArneBab>mange: I’ll try out the guix-ruby channel. Thank you again! <gabber>xxd: i think that is correct. there is no "default" guix (think: desktop and all that jazz). but you can easily craft an image that you can flash onto a pendrive and make it boot <xxd>gabber: Are there examples? <xxd>I suppose the system images docs should work. <Rutherther>xxd: the installer ISO is a live image. You can poke around, though mostly in a tty. You can try reconfoguring to a gui system if you needed that, but there might be a few caveats. <nikolar>it doesn't exist as a standalone package at the least <mange>nikolar: I've definitely used clangd. It looks like it's in the clang package. <Kabouik>gabber: noted. Also if I don't manage, maybe we could try reaching the people who contributed to the package, see if they needed some manual steps (I remember distrobox needs some manual steps that are not documented for instance, and the person behind the patch helped me by email). <Kabouik>Though, for clamav, the initial patches is from 2016. <gabber>Kabouik: usually posting to help-guix (and/or guix-devel) mailing lists reaches those involved <hugohugo>I'm getting a ice-9/boot-9.scm:1685:16: In procedure raise-exception: <hugohugo>error: %substitutable-nar-size-procedure: unbound variable <hugohugo>rg "substitutable-nar-size-procedure" does not show anything <cbaines>I think I've seen some messages suggesting this relates to stale .go files <hugohugo>oh that could be. Sorry for being so direct/vague, was still investigating <hugohugo>I did 'make clean-go', but is there also something like 'make go'? 'make' is now compiling the italian manual, which is not terribly urgent for me <ieure>hugohugo, Not sure, open the Makefile and look? Building the manuals doesn't take very long when I'm compiling Guix. <hugohugo>yeah couldn't quickly figure it out, but I can wait <Kabouik>I think I got clamav running csantosb, gabber. I'll do some more testing and try to write down what I needed to do to share in help-guix. Nothing fancy actually, it's mostly about generating several conf files in non-default directory (otherwise it tries to write in its /gnu/store directory) and setting a few options. I think. <gabber>maybe we could patch the package so it tries to write stuff in /etc and /var instead? <gabber>my pinebook pro can't find wireguard kernel modules. do i have to add them somehow? it runs non-liberated linux 6.16.8 and has wireguard-tools installed system-wide <dariqq>something seems to have broken my custom updaters <dariqq>i guess it is 15f87a0f037ec9b4f5045965416652670ffd955f and that i use my channel from the load path directly <dariqq>Actually pulling from my channel and they work again. <Guest21>hello, is it possible to build an image with Guix System that does include my Guix Home as well? <ieure>Guest21, Yes, add guix-home-service-type to your operating-system's service list. <hugohugo>head -n1 $(guix build texlive-texaccents | tail -n1)/bin/texaccents <hugohugo>"This small utility, written in SNOBOL, converts the composition of special characters to Unicode." <FuncProgLinux>Guix cannot import go on OpenSUSE :( it fails with an sxml error <jonsger>FuncProgLinux: from which source is your Guix? on which openSUSE distro are you? <FuncProgLinux>jonsger: The provided from the openSUSE repositories which I have updated to a commit earlier today.