IRC channel logs


back to list of logs

<nckx>sneek: later tell wehlutyk [I replied earlier but it seems to've been lost.] I suspect I approved your message and whitelisted your address. That doesn't expire, so something must have changed.
<sneek>Got it.
<nckx>sneek: later tell piptown Hm... 'source' implies to me that you perhaps forgot to make it executable?
<sneek>Got it.
<nckx>sneek: botsnack.
<civodul>looks like we have a serious firewall issue with berlin:
<civodul>clients being blocked for alleged "DoS attack", à la Cloudflare, but home-baked
<civodul>ACTION -> zZz
<joeljuca>Hi. I'm not a Guix user; I'm still exploring things around. I have a [possibly quite newbie] question: can I use Guix in a traditional Linux distro, like Debian or smt, as a stand-alone package manager?
<singpolyma>joeljuca: yes. apt install guix
<joeljuca>singpolyma that simple? 😅
<joeljuca>Thanks! I'll try it w/ Debian then
<porcupirate>I tracked 2 bugs specific to guix's version of renpy down to their source and filed a bug report for each. If anyone's looking for a straightforward fix, I recommend bugs 65252 and 65253.
<ardraidi>Would packaging the scream unix receiver be acceptable in Guix?
<jpoiret>ardraidi: seems to be under ms-pl, which is free software according to, so i think it would be ok
<ardraidi>jpoiret: Thanks. It's a receiver for a virtual card for MS Windows. Couldn't find a transmitter for Linux or something else. Would it still be OK?
<jpoiret>I don't have any opinions on this, but if there's no transmitter for Linux there might be some discussion on it. You can send a quick mail to guix-devel with these details if it's troubling you
<ardraidi>jpoiret: Alright. Thanks a lot.
<ulfvonbelow>when looking through glibc headers to scrape data for (guix build syscalls), how should one handle definitions that are conditional based on whether __USE_FILE_OFFSET64 is defined?
<ulfvonbelow>for example, F_SETLK seems to be either 11 or 8 on hurd depending on whether __USE_FILE_OFFSET64 is defined or not
<jpoiret>why are you scraping the glibc headers for this?
<jpoiret>i don't think we should try to duplicate all the hard work that glibc does
<ulfvonbelow>because it's either that or build guile extensions in C, and I am told this is preferred
<mwette>ulfvonbelow: which header for F_SETLK?
<efraim>we (manually) scrape the gcc sources and duplicate them in guix/cpu.scm
<efraim>__USE_FILE_OFFSET64 is per-architecture or per-build? or some other option?
<civodul>efraim: per build, but you'd do -D_FILE_OFFSET_BITS=64 (the __USE macros are internal)
<Guest28>How can I change my DNS servers?
<nckx>Guest28: Depends on how you configure your network. If Guix manages your network through the static-networking-service, as is common on servers, there's a name-servers field. *Most* people use something like NetworkManager or connman or …, which all manage DNS on their own as part of the connection presets. In NM's case, you'd use a GUI like nmtui to edit your settings.
<Guest28>nckx: Ah so basically I need it todo it the classic way.  Thanks
<Guest28>Thought I need to configure it since Guix
<aarcov>I'm trying to edit a package definition (eternalterminal) to fix a build issue; I believe that the problem is related to a change in glibc (, and am attempting to build against an older version. The problem is I don't know how to change the version of glibc that Guix uses for the build. The method that I'm trying seems to cause it to not properly pass in the inputs.
<aarcov>Pastebin to master build:
<aarcov>Pastebin to modified build:
<PotentialUser-60>Why it takes guix longer to port latest version of GNOME?
<PotentialUser-60>Other fsf distro have a more latest version of GNOME (trisequel,pureos)?
<aarcov>If I had to guess it is a mix of two things, time for a person who wants to upgrade it to submit a patch
<aarcov>and dependent on the release cycle:
<aarcov>I suspect Gnome would hit the core-updates branch
<Guest28>aarcov: You mean glibc as package input or the build system?
<PotentialUser-60>What is core-update branch?
<aarcov>@Guest28, as an input, although if there is a way to specify to have guix use an older toolchain with the build system that might work as well
<Guest28>aarcov: That is easy.  Depends on the syntax you use, but it is either glibc:2.33 or glibc-2.33
<Guest28>glibc@2.33 not glibc:2.33
<aarcov>in the build scripts? it doesn't seem to like the package@version inside of the scheme files
<hako>`pacakge-with-c-toolchain' ?
<aarcov>currently using the cmake toolchain, I'm trying to edit the broken build script
<nckx>aarcov, PotentialUser-60:
<nckx> might be a better link.
<nckx>ACTION -> food.
<Guest28>aarcov: I mean like this if you want to replace the whole toolchain, I don't know how this works
<Guest28>the make@4.2 in that case
<aarcov>hmm, it still has the '-' though later where it specifies the actual package name in the sourced file: ("make@4.2" ,gnu-make-4.2)
<Guest28>Yes, that is correct for the old syntax.  New syntax would look like (native-inputs (list gnu-make-4.2))
<aarcov>Guest28: ok, that process worked to pass in the package version (seems I added some typos earlier)
<aarcov>which syntax is considered the 'new' way to do stuff going forward?
<nckx>You probably could have written ("blorp" ,gnu-make-4.2), the label doesn't have any required 'syntax'.
<PotentialUser-60>Is there any set/specific date for major releases?
<PotentialUser-60>So it is kind of when it is ready it will be released? Is there any way to get bata builds?
<nckx>Kind of. Releases aren't very meaningful since Guix is rolling release. Beta, no, because the only difference between a 'latest' snapshot ISO and a release ISO is that the latter is better tested.
<aarcov>seems my hope to make glibc an input to downgrade it didn't work; is there a recommended way to downgrade something such as glibc (or maybe the toolchain to an older version)?
<nckx>In general you're not missing anything. There are git branches that collect updates that cause mass rebuilds, but on average they contain fewer updates than the master branch.
<efraim>aarcov: for eternalterminal is there a reason you're not upgrading it to a newer version?
<aarcov>efraim: I actually have it building for versions 5.1, 6.1, and 6.2 with minimal edits
<aarcov>I'm trying to figure out how the packaging system works better, and 6.0 is a gap in the ones I'm able to build
<aarcov>with that said, whenever I get around to submitting a patch, what are the rules on old versions? for a program such as this, would the best patch replace the existing 6.0 with version 6.2? or should I also include all the other versions?
<aarcov>I'm assuming for libraries that follow semantic versioning we want the latest minor version for each major version of the library?
<nckx>aarcov: We generally keep a single version, unless there's a 'good reason' (fsvo good) to keep multiple.
<nckx>If there are no users of a older library in-tree, it's generally tossed.
<aarcov>ok, if I try to bring in a rust program that depends on a bunch of different versions of packages, would it be better to submit the whole thing in one patch or a patch per library?
<nckx>One patch per package is the rule.
<Guest96>Trying to figure out why my certbot service is not generating anything in /etc/letsencrypt/live/.  Is it possible that my nginx server is interfering?  They both serve http over port 80 it seems
<efraim>also the rust-team branch should be merged into master RealSoon™
<Guest96>Alright, figuring out how to run certbot manually was very insightful.  Seems to work now.
<aarcov>I'm trying to setup how I will generate some patches to add to master, but I'm having some errors with setting up the direct-checkout method in the Guix Cookbook (, I'm using this setup (with errors included):
<aarcov>Do ya'll use this approach, or is there a better method to making a temporary copy of the master branch, editing it, running some final tests, and then generating the patch?
<nckx>aarcov: You're launching a development shell *for* gcc-toolchain.
<nckx>You should need little more than ‘guix shell --development guix’, maybe one or two optional packages.
<nckx>As for ‘y'all’: the manual suggests ‘guix shell -D guix --pure’ but that's a bit too hard core for me. But in general, yes.
<aarcov>nckx: welp, it seems that fixed that part, thank you
<nckx>(With hardcore, I meant the ‘--pure’.)
<Guest96>I think I fonud an error in the documentation.  The nginx docs give an example config for an http only server.  The problem is that the example leaves the "listen" field default for the nginx-server-configuration, which includes "443 ssl".  At least when I tried this, nginx failed to start complaining that I gave "443 ssl" but no ssl certs.
<Guest96>are documentation errors "bugs" that go to ""?
<nckx>Guest96: Yep!
<pastor>guys. Does anyone know if this is a known bug? I'm building a system configuration which is divided in two files, a base system and a machine specific one. Both of them are in the same folder but I get this output:
<pastor>guix system build -L . sheepbook.scm
<pastor>error: %base-xfce-system: unbound variable
<pastor>hint: Did you forget `(use-modules (xfce-system))'?
<nckx>pastor: You got quieted by a bot. Use for many-line pastes, although I think all your lines got through this time.
<nckx>pastor: Did you use-module that module? It should probably help to share at least sheepbook.scm as well.
<pastor>My bad. Btw, I'm `grim` I should make an account for IRC 😅
<pastor>sure. Yeah I did. Let me prepare the pastebin
<pastor>nckx: Here you have both scm files:
<pastor>The thing that makes me think it's a bug is that it's building fine
<frog>pastor: does "guix repl ./xfce-system.scm' produce any errors?
<nckx>(Yes, a missing root file system.)
<pastor>frog: noup. No errors on my side
<nckx>pastor: I'm currently building gnome-control-center. When is that error supposed to happen?
<nckx>Ere I build all of GNOME for naught.
<pastor>nckx: before everything
<pastor>the thing builds fine. But the error appears before even starting fetching substitutes
<pastor>the lines I pasted when the bot got angry where all the lines
<nckx>Hm, here it doesn't appear before it starts building g-c-c.
<pastor>but even when the error appears the appropriate system gets built. I'm actually typing on that system
<pastor>interesting. Which version of guix are you on?
<pastor>I'm here `guix (GNU Guix) 9350347dabd0f25f89fd2a703a250b20872ad911`
<nckx>Something based on 77251c5f5af193dcd031dffef744001cfc48f7e5 (with irrelevant commits), but I don't think this is a Guix version problem.
<nckx>I assume I'd get your error if I had more of GNOME built/downloaded locally, so I'll let that happen. I'll be on the road for an hour anyway.
<pastor>nckx: thanks
<nckx>For the record, I do think there are bugs in how ‘guix system’ deals with -L, although they might be harmless in this case. Error reporting often gets very weird.
<nckx>ACTION away.
<zaha>Hey y'all, was wondering if there's a straightforward way to look up what module a symbol belongs to. Like for example if I want to find the module "home-files-service-type
<Guest96>Oh no, guix's exim doesn't come compiled with maildir support?
<zmhanham>sry accidentally hit enter early... How should I search for the module that package belongs to in the easiest way?
<zaha>*module that symbol belongs to
<Guest96>Personally, I would just "grep home-files-service-type -r /path/to/local/guix/clone", but there is probably a better way
<zmhanham>makes the most sense thanks, could probably make an emacs command to do just that lol
<gnucode`>hey guix!
<zmhanham>howdy! :D
<gnucode`>zmhanham: :)
<Guest56>hello Guys! Is there anyone who uses Guix as a daily driver?
<aarcov>Does anyone know of a way to temporarily disable custom channels when doing final testing against master before generating a patch (other than temprarily renaming the channels.scm file)?
<nckx>Well, ./pre-inst-env has that side-effect and is what most people use.
<nckx>(Source: mah butt. But it *feels* plausible and that's what counts.)
<nckx>zaha: It's not a general-purpose answer but for these there is guix {,home,system} search.
<aarcov>ah, that's what I was missing with the ./pre-inst-env; although it doesn't seem to play nice on my foreign install?
<nckx>It does still expect to be run inside a 'guix shell -D guix' environment. The -env is misleading in that regard.
<jonjojojon>Hello, how well does guix sd work with languages (specifically julia) that don't play well with external package managers. This is the main language I use that doesn't work well with guix so far.
<efraim>You're in luck, I'm one of the main people working on Julia in Guix. It works reasonably well, as long as you've matched the dependency versions as needed. Julia can download newer versions as needed. the main thing is to use Guix packaged XXX_jll packages, since they need to link against guix packages, the rest works well enough with upstream
<efraim>Also, if you know another distro that is packaging julia packages/libraries, let me know, I'd love to see how they're doing it
<civodul>efraim: hey! there's this importer that could probably make the life of Julia packagers easier:
<civodul>would be nice if it could be merged i guess
<nckx>sneek: later tell pastor When I remove all lines that cause an error on my system (due to missing third-party channels), the system builds fine. No ‘%base-xfce-system: unbound variable’. When I uncomment one of them (say, ‘(specification->package "abstract-sddm-theme")’), the build fails AND it produces that ‘error’.
<sneek>Will do.
<nckx>sneek: later tell pastor I can't, unlike you, create a situation where it successfully builds AND throws an ‘error’, but there's definitely something off about error reporting and -L.
<sneek>Got it.
<nckx>sneek: attack of the 50-foot botsnack.
<lilyp>sneek: the botsnack was humans all along