IRC channel logs
2023-09-29.log
back to list of logs
<nckx>I certainly understand it's not traditional though (our Linux journeys, or at least starting points, are not dissimilar). <graywolf>Can you run guix system reconfigure twice in parallel or is there some locking in place? <nckx>Everything built by/inside Guix locks just fine, but I'm not sure about the final GRUB installation. <nckx>(I wouldn't recommend running grub-install in parallel on any distro, but that's beside the point.) <ulfvonbelow>today I learned that in the year of our lord, 2023, exim disables ipv6 by default (HAVE_IPV6=yes is commented out in src/EDITME) <graywolf>Hm, it looks like guix is assuming that guile-git returns always the same object for the same commit. That seems... unwise? libgit2 uses a cache of a limited size, and it can be pruned. After all, it is just a cache. Would anyone know a reasoning behind this design choice? <graywolf>I discovered this because (@ (guix git) commit-relation) fails in my guix fork, I assume due to this. <graywolf>I am still debugging this, so I am unsure about the cause, but the design seems weird, so I am asking. <mirai>ulfvonbelow: 32bit ought to be enough <mirai>& NAT is much more intuitive compared to subneting /s <ulfvonbelow>heh, right now I'm migrating to dual-stack and simultaneously having and not having NAT is throwing everything off <mirai>IPv6 takes away port-forwarding from the poor commonfolk <ulfvonbelow>the main domain now hits the router's NAT with its ipv4 address, but the primary machine behind the router with its ipv6 address <ulfvonbelow>so using the same domain with certain port numbers may result in different machines being reached depending on whether ipv4 or ipv6 is used <graywolf>Ok, so the cause isn't cache being pruned, but the commit object being too large to even be stored in it. The end result is the same however... <PotentialUser-47>Hi there i am trying to create a custom package for the helix editor but i am encountering an issue seemingly where my PATH variable is not inherited when I invoke build <PotentialUser-47>this causes a git derivation to not recognise the { basename, sed, uname} program-s <PotentialUser-47>should the build command inherit the environment, or am I doing something wrong? <ulfvonbelow>builds are performed in an isolated container with only the inputs available that were explicitly or implicitly declared by the package <ulfvonbelow>as such, the value of environment variables in the process that invokes 'guix' should have no impact on the value of environment variables within the build environment <ulfvonbelow>I bet if you pasted your WIP package definition, someone could help <PotentialUser-47>so the channel consists of "lucyChannel/packages/helix.scm" and "lucyChannel/packages/rust-software" <PotentialUser-47>i am calling the build process from the directory: ( lucyChannel/packages/) using `guix build -L /home/lucy/Projects/GuixChannel -f ./helix.scm --keep-failed` <PotentialUser-47>the build used to manage to clone helix alright but after some issues with my system, i have my system working again but this is occuring <smiley1>Hello, new to guix, trying to find documentation or tutorials for using guix to build a local, private repository for development only (lets say elixir to start). Any advice? <jaeme>smiley1: Look at the guix documentation for creating a channel <jaeme>Its as simple as creating a git repo that contains a guile module with all your package definitions. <smiley1>okay thx. Ill start with creating a channel then ping yall when I run into something. the docs are pretty expansive so finding path thru a slightly uncommon workflow can feel daunting. <veriphile>Does guix have some sort of supervision in its daemon-runner/service-manager? <user363627>in guix, how do i figure out items that depend on a particular entry in the store? <janneke>sneek: later tell user363627: there is guix gc --list-dependent, but for packages; does that help? <user363627>janneke: i don't see list-dependent, but i do see --referrers which i think gives something useful <sneek>Welcome back user363627, you have 1 message! <sneek>user363627, janneke says: there is guix gc --list-dependent, but for packages; does that help? <janneke>user363627: my bad, that's guix refresh <user363627>for guix refresh to work i need to be able to convert store location to package. i'm not sure how to do that <janneke>right, sometimes it's an obvious guess and sometimes it's not <user363627>for the paths in question the version numbers are identical <user363627>so i'd need something more specific to refer to them if i were to do so as a package <user363627>i think guix gc is probably the more direct way for what i need <user363627>on a somewhat related note, on a non-guix-OS with guix installed, what's the practical difference between /root/.config/guix/current and ~/.config/guix/current ? <janneke>each user has it's own guix profiles, they only share the system profile <janneke>running `guix pull' updates a user's (current) guix <user363627>so ${HOME}/.guix-profile is the default profile. ${HOME}/.config/guix/current is ${USER}'s current profile. and /root/.config/guix/current is root's current profile. when is the ${USER}'s current profile used vs root user's? and which is the system profile? <user363627>with sudo -i guix pull affecting the version of the guix daemon <kaizer>Ssup guix, hope y'all are doing just fine. First, I wanted to say thanks, I asked about some patches and in less than a week those patches were made. This wasn't done for me and that's what's amazing about this community. As a free software enjoyer aspiring to be a free software developer, thank you, all of you, what you're doing is amazing. <kaizer>Naturally, secondly, as a free software enjoyer, I have even more problems. I wanted to add the wasm32-unknown-unknown target for rust and according to the manual all you have to do is add the files to the rust install directory under lib/rustlib folder. Now, everything in guix is read-only, linked files so, I'm stumped. How do I solve this problem my fellow guix? Thanks <gabber>my $(sudo guix system reconfigure config.scm) fails due to "configure: error: Git is missing; please install it." which doesn't /feel/ right <gabber>i'm on commit: 1b0ec97bce2db93ec4159a13fb0a184f012df4fe <kaizer>That one got me too, just add git to the deps <gabber>do you mean the (packages ..) field in the operating-system definition? <kaizer>yes, you can also just install it for the user only, using guix home, but honestly I think it should be on the system itself, so the packages definition in etc/config.scm is where I put it. Don't forget to import the module itself, but you'll get a warning from guix with the right module if you don't <kaizer>plain guix install should also just install for the user alone. You can use that to test for what you ultimately want in your sys config <minima>i see some variable names prepended with a `%' sign in guix's codebase and i understand that's mostly for constants; however, some of these variables are defined using `make-parameter', therefore they are meant more like a "constant that can be tweaked"? am i understanding it correctly? <minima>i'm asking because the concept of constant would seem (to me) to clash with make-parameter's objective <kaizer>I haven't gone through guix's codebase myself but what I do know is that these "constants" can be modified eg %desktop-services can be tweaked to specify the login manager <gabber>minima: AFAIK there is no concept of concept in Guile. you can (define ..) so that a name (first argument) is bound to the second argument within the current context. you can import these defines, but there is no prevention from other context not set!-ting these names to new/other values <minima>gabber: i see, thanks, although that follows the lexical binding mechanism unless you use something like make-parameter, and then you have a dinamically-binded variable, if i understand it correctly <minima>yeah my question was more along the lines of... if it's defined with make-parameter, then why mark it with a leading `%'? <minima>i have an intuition of why it makes sense to do so, but i wanted to get some validation <minima>yeah `%desktop-services' is a good example <rekado>minima: it is only for communicating intent. <rekado>“this is a global piece of data defined elsewhere” <civodul>janneke: doesn’t ring a bell; 59587e2fda76c19b424fda9a987ff90d52ef217e does add Git to the inputs <civodul>(commit log missed that info actually) <civodul>oh i can reproduce it with ‘guix system build’ <civodul>oh it’s cross-compilation to i586-pc-gnu that fails <janneke>hmm, (but) would gabber and kaizer both have a childhurd as part of their configuration? <gabber>although it's called hurd-vm-service type ;) <janneke>gabber: sure, it's spelled "hurd-vm", but it is (can also be) pronounced "childhurd" ;) <nutcase>I added bind:utils to my system profile. However, the utils aren't linked into my PATH, e.g. I am missing /run/current-system/profile/bin/dig. What could be the reason? <minima>rekado: hey, thanks! that seems to confirm my intuition, super <gabber>janneke: thanks, my system is (re-)building now! <janneke>civodul cbaines: this must be the 3rd time "we" tried to upgrade to guix (revision 11) and found something silly; wouldn't it be nice (TM) to have a "make update-guix-package && guix build guix|something" thingy in ci? <cbaines>janneke, I don't know about CI, but for QA, I guess we're missing information regarding cross builds and system tests <janneke>cbaines: quite possibly /me meant CA <cbaines>we are doing cross builds, so there just some work to be done to show that information on the page for issues (and submit the cross builds for the patch series) <cbaines>system tests are a bit more complicated <civodul>cbaines: cross-builds would be nice, though we’d have to be selective (maybe a single cross-compilation target would catch most issues) <janneke>it's not meant as criticism, it's just the observation that it seems easy to break either building the "guix" package (after a fresh update-guix-package), or using it, without noticing it <cbaines>we're only computing derivations for cross building from x86_64-linux, but testing that should still help <janneke>then whomever runs `make update-guix-package' might be confronted with several different kinds of breakages <cbaines>on the subject of QA, if anyone is interested in trying out the new "Mark patches as reviewed" feature, please give it a go! <cbaines>civodul, sort of, although it involves sending an email <cbaines>the QA frontpage will then highlight issues with that tag <civodul>if there’s an extra badge, even better <cbaines>good good, the reviewed ones will show up in a darker green at the top <cbaines>I've also started trying to add more statuses for issues <cbaines>so the /patches page will now show different colours for things like the data service failing to process the revision, and the patches failing to apply <civodul>yeah i noticed different colors recently but i wasn’t sure what they meant <zimoun>civodul, yesterday we were drinking beers with Guixers at April. Nice! Someone has a weird issue: impossible to “guix pull” or roll-back. The culprit: an empty manifest file. How is it possible? What can go wrong? <sneek>Welcome back zimoun, you have 2 messages! <sneek>zimoun, efraim says: I'm looking at the julia stuff again, should lapack be an input for openblas? <sneek>zimoun, efraim says: I'm looking at the julia stuff again, I think we might need to change the pkg-config file for openblas-ilp64 so it doesn't overlap (-lopenblas) directly with openblas <zimoun>(The bug report should come with details by Someone) <gabber>btw thanks for that super-quick response time, janneke and civodul <zimoun>efraim: thanks for the push. Now the state of green. Well, I am in favor for the status quo for now and revisit for the next update of Julia (1.9 or 1.10). <janneke>gabber: thanks for reaching out and reporting it here <civodul>zimoun: corrupt file system? (nice that you had this meetup!) <zimoun>civodul, yeah cool meetup! Hum, I do not think but why not. <kaizer>Fellow guix, I might have to give up on the guix shell approach for rust development. I can't use my awesome emacs rice with guix shell! Unless I create a separate emacs installation. I use doom emacs so I'd have to byte-compile it again and maintain both instances. I feel like there is a way around this, but I haven't thought of anything yet. The --share and --expose options are not working as I expected. Any pointers? <gabber>my $(guix system reconfigure config.scm) seems stuck for a suspiciously long time after "guix system: bootloader successfully installed on '(/dev/nvme0n1)'". should i wait? restart? pray to the holy GNU? i doubt i am doing it inherently wrong <nckx>I assume the $() is just decoration and you're not actually swallowing output? It sounds like you're at the point where Guix is restarting (some) services, and yes, this can IME rarely hang for unclear reasons. <nckx>The good news is the ‘installation’ part is finished. <nckx>So ^C shouldn't lead to anything missing. <gabber>thanks for the insight and yeah, $(..) is just the decoration/delimiter to show how i executed which command <nckx>It's also meaningful (and not infrequently used) in bash, so keep that in mind. <gabber>i know, that's why i chose this particular formatting - instead of the nowadays less(?) used backtick in-place execution `echo hello` <xelxebar>Yikes. 64.185.228.34 is hammering my guix-only address with the same email every few seconds. <nckx>That is one of those meritless gTLDs I blanket block on sight. <mirai>couldn't rejecting at SMTP level or simple sieve script do the job? <ted-ious>I don't know about mail but lots of new tld's seem to be used by useful little websites that are made by individuals so I want to be able to reach them. <nckx>I use OpenSMTPd and filter on rDNS. <ted-ious>So I guess I can't just treat them all like spam. <bjc>the only gtld i'm considering dropping entirely is .zip <bjc>honestly, i'm also seriously considering dropping dns for it, too <ted-ious>Is that one full of spammers trying to use confusion exploits? <bjc>it's one seemingly invented for exploiting people. and google's coffers, of course <nckx>.exe doesn't yet exist because we're only in the 5th circle of hell. <xelxebar>But .top is apparently one of the most popular gTLDs. <nckx>I just don't want to receive mail from any of them ☺ <PotentialUser-43>Hello Guix. I want to package a bigger inhouse Java Framework. It is build with gradle so not much luck with the build from source approach. I have an archive with all the .jars. Can I just use copy-build-system to put it into /opt (thats the normal position( or will it better be part of the store? <nckx>You can't install anything into /opt, in fact nowhere outside /gnu/store/$your_hash-$your_package, so that's that settled. <ahim>Hi, I had trouble arriving at the blue screen to install GuixSD with a USB on my T440p but then, I burned a DVD and then I could install it with some error message but I cannot boot it afterwards. I see the grub and then it the logo of Guix with gray background. The message was: missing free siftware, nouveau, bios ctor failed: -22 unable to locate <ahim>usable image but then the installation carried on. During the installation on the blue screen I got : your graphics hardware possible does not work, expect trouble! Perhaps pass "nomodeset" to the kernel args and need to configure uvesafb kernel module. I am a bit stuck here. Thanks <nckx>I don't know about uvesafb, but trying ‘nomodeset’ is relatively easy: when the installer first boots, you'll be presented with a (GRUB) boot menu that says something like ‘GNU Guix Installation <VERSION>’. Instead of booting this, press ‘e’, then edit the (long) command line starting with ‘linux’ to add the word ‘nomodeset’ at the end. Then press C-x to boot. <nckx>s/Installation/ / since I guess this is talking about the installed system. <nckx>I also recommend mailing the help-guix at gnu dot org mailing list, since any T440p owners might not be lurking here at the same time as you. <ahim>Hi nckx, I think we talked here yesterday too. I added nomodeset but it did not work. I will email them, thnx anyways! <nckx>Ah, sorry, I don't remember (nothing to do with you). <avalenn>IRC logs search on logs.guix.gnu.org seems to be stuck on last January. <rekado>nckx: I’m dense. What’s wrong with the line numbers? <rekado>oh, I see that it does a +2 on every line <rekado>as long as it’s not alternating I’ll allow it. <nckx>In the linked example, ‘Toggle quote (N lines)’ is off by +1 by human standards. <rekado>yes, all the line numbers in that email (including the anchors) are off <nckx>‘That’? Joy. Is this somehow my fault again. <bla15e>Was there a change in the behavior of how channel modules are put into the guile %loadpath? Previously, I was to be able to use my channel's modules in a guix repl, but now I'm getting 'no code for module' for using 'use-modules'. I'm still able to load my channel's modules in my system and home configurations, but unable to do so in `guix repl` <bla15e>For example, my home configuration is something like this: <bla15e>This works just fine, but I get the following in `guix repl` <jpoiret>bla15e: in a repl, you need to load the (gnu packages) module first for the loadpath to include channels <nckx>I mean s/it/our package/. <nckx>IceCat should be taken care of by b2ab38cd82acd8164383335af084f5da4a499332. <nckx>(For those reading only the lines: upgrade your system, this is supposedly being exploited in the wild.) <rekado>nckx: that’s not what I meant to imply. I have only looked at this one message, so I was only able to make a statement about lines in that particular message. <nckx>I'm used to weirdness being local to my presence. <x4d6165>is there a way to specify channels in the config.scm file? I'm trying to specify my channels during install <nckx>I guess you could use inferiors, but the sane answer is no. You could provide a default /etc/guix/channels.scm for *subsequent* guix pulls though. <graywolf>Hi :) Should modifications to guix/git.scm have the commit message starting with `guix: git:' or `git:'? <lilyp>probably guix: alone is fine <graywolf>That is the only option not visible in git log -30 on that file ^_^ But will do, thx. <graywolf>Just a personal datapoint: It is bit confusing sometimes that it looks like even committers cannot agree on how it should look like :) <rekado>I’m having a weird problem with inferior-packages <rekado>it fails in guix/inferior.scm at line 415 because one package appears as a name+version list, not as (name version id) <rekado>unfortunately, this behavior is not reproducible <lilyp>graywolf: ae587c2ef041413bc709a555261db752068ea360 <lilyp>Although that does touch a little more than just (guix git) <lilyp>hmm, seems like git: has prevailed recently