IRC channel logs
2024-08-28.log
back to list of logs
<PuercoPop>Looking at the git history of cargo-build-system's file I see the use of build: cargo-build-system: and build-system/cargo:. Is there a difference between them? Are the prefixes used somewhere for tagging or assigning submissions? <AwesomeAdam54321>PuercoPop: guix/build-system/*.scm is used for defining the build system interface used by packages, all the builder-side functions are defined in guix/build/*-build-system.scm <PuercoPop>AwesomeAdam54321: Yeah, the commits I'm looking at are all changing guix/build/cargo-build-system.scm <PuercoPop>I want to change the install phase so that it works for virtual workspaces also <PuercoPop>Is there a way to setup a breakpoint to the guile debugger when callin guix build? <robin>i *constantly* mix up build and build-system. i suppose i should just remember that "build-system" is the field actually used in package definitions <Troler>I've been facing issues with guix package manager <Troler>I can send the image or log the file <Troler>Though I am not sure where the error message log file is stored <Troler>Documentation seems to say --log-file is needed to make one <Troler>Basically my issue is that I get an erronous error message after pulling packages using `guix pull` command <Troler>If needed I can transcribe what is written on the image <Troler>Note, I have allocated ~5Gb to /gnu/store <Troler>Note, I have allocated ~5GB to /gnu/store <apoorv569>What's the best way to mount NFS share on a Guix system? just put the config in file-system with type nfs? <apoorv569>That won't check for network access when mounting it though, is there a way to add network as like a dependency? <apoorv569>like check if there is network access only then try to mount NFS.. <apoorv569>This is for nfs server AFAIK no way to specify mounts.. <fnat>Oh sorry, nvm, that's for exporting. <apoorv569>Yea, for now I use `file-system` only.. which works.. but would be great to add the network dep.. <amano>I heard that it takes a day or two for substitutes to be available for the official guix channel packages. Perhaps, can the packages be released after substitutes are built? <amano>I mean there can be a dev branch and a main branch. Packages will be pushed to the main branch after dev branch packages are built as subsitutes? <pjals>Hello, I could've sworn that there was a service type for spinning up a guix system container, does something like this exist? <pjals>I've looked around in the manual and can't seem to find it <amano>Do users still have to wait a day or two for substitutes to be available? <pjals>Thanks! That looks like what I'm looking for (could've sworn it was in base guix!!) <amano>Are substitutes released along with packages? Or, are substitutes released a day or two after packages? <nckx>They are served when they are ready. Pushes to master trigger the CI which schedules a build. <nckx>amano: What do you mean by ‘what do you mean’? The ‘yes’ was an answer to your question above it. <amano>Can I expect substitute for every new package? <amano>I read that substitutes may appear a day or two after a new package is released. <nckx>(cont'd) Having a delayed master branch triggered by CI is an obvious idea that I'd wager is about 2 seconds younger than CI itself 😉 Nobody's found it worth implementing though. <AwesomeAdam54321>amano: The availability of default substitutes are usually delayed, since the substitute servers need to catch up <amano>AwesomeAdam54321: I wish substitutes are released along with packages. <nckx>Wishing is cheap, write the code. <amano>nckx: This one doesn't require writing code. <amano>It only requires changing deployment practice. <amano>For example, collect everything into build branch. Build everything in build branch. After build is complete, publish build branch to main branch. <amano>This way, you can make sure substitutes are available for every package. <nckx>Yes, as noted before, the idea is trivial and obvious. What's missing is the work. <nckx>Simply restating the idea here won't change anything. <amano>By the way, is it possible to prevent local build for default packages? <nckx>I challenge you to write the code, or ‘deployment practice’, whatever you want to call it 😉 <amano>Changing deployment practice requires some power in gnu guix core team. I don't have that power. <nckx>There is no team. Also, welcome to the team. <amano>If I can prevent local build, then I can force low-resource computers to wait for substitutes for every package. <nckx>You could hack something together (poll for substitute, wait/fail if there is none, repeat) but there's no built-in option for that AFAIK. <amano>I'm sure every linux distro has inner circle. I'm in the inner circle. <amano>How many packages do you end up building usually? <amano>How many packages does a guix user expect to build for each update? <nckx>You are in the inner circle if you submit patches and respond to review. There is no secret cabal of maintainers that makes policy decisions behind the scenes. Just a not-so-secret cabal of maintainers that sends a lot of e-mails and pings avp_ to no avail. <pjals>how do we know there's no super secret guix club?! <weary-traveler>well clearly nobody here is part of it. violating the first rule left and right <amano>The maintainers are the ones who accept the patches... <amano>Maintatiners have more power than contributors.... <nckx>None of the ideas I've read so far are new. In fact most of them are quite old. That doesn't mean that they are bad. In fact most of them are quite good. <nckx>But rather than restating them for the Nth time and hoping for the Guile fairies to design and implement them (they are lazy buggers), you need to step up and work through their detailed implications and either motivate someone to work on it (good luck) or (more realistically) get your hands dirty. <nckx>This requires familiarity with the basics of Guix, which you don't seem to have, even before you get familiar with the code base. That's normal, but it's work *you* have to do. <nckx>There is no need or advantage to being a 'maintainer' or team member. It will not change anything. Trust me. <nckx>I'm a rando on the Internet, you knowe <weary-traveler>importantly, commit access isn't a pre-requisite for being able to write said code <nckx>And if your patches are useful, why would committers (we don't call them maintainers because then we'd have to pay them) not accept them? I don't get that logic. <nckx>Committers mostly commit other people's work already. It's even encouraged. <rhuijzer>What's the workflow for core-updates? I would really love to have an up to date libusb, current (quite old!) version breaks my workflow, but my patch was (rightfully !) rejected a couple of months ago because it required rebuilding of 3000+ packages. I didn't know how to check that yet. So It would be great to have the update in core-updates and I'm willing to help testing. How do I get it there? Does the communication happen on the mail <weary-traveler>i do think working closely with someone with commit access can be helpful. but the help there is mostly psychological (albeit no less real) in nature. similar to mentors in kernel development or peer in pair programming - it can provide feedback faster <amano>I don't want to do everything under the sun. That's not possible... <amano>You can do any one thing well, but you can't do everything... <amano>I'm just throwing some ideas... here... because I don't have time to do everything under the sun. <weary-traveler>amano: of those ideas, which is the one thing you do intend to do? <amano>I'm just hoping that someone will pick up the ideas... <amano>At least, if I didn't tell anyone, nobody would have thought about my ideas... <weary-traveler>i see. so it's not that you don't want to do everything under the sun, you only want to talk about doing? <amano>Talk is actually important... <pjals>like some hobbyist who made some obscure kernel said, "talk is cheap, show me the code" <amano>pjals: If you talk in mass, the world changes, but I'm not doing mass speech through media. <amano>Is it possible that a low-resource laptop ends up building rust and firefox due to absence of substitutes? <amano>Hmm, perhaps, I should just wait a few days after updating packages? <nckx>And now some personal opinion: it's easy being the 'idea person'. Most 'idea people' come into a space, make some simple observations, then... nothing. Like coming into a house, noting 'the door is cracked', like we didn't know, or were merely waiting for that observation to fix it. <Rutherther>Yes, can happen, just use guix time machine and guix weather to check if stuff is available to revision you intend to switch to <amano>nckx: I'm guaging viability of guix as a distro for a low-resource machine. <nckx>There are much better ones. <Franciman>yes also computing profiles is kinda expensive <amano>Do I want at least 32GB on a laptop if I want to use guix? <Franciman>problem is the amount of computation guix pull does <amano>I compile everything on gentoo linux, and 32GB would be the minimum I require for building everything for a desktop linux system. <amano>I compile everything in RAM. <Rutherther>amano you can always just deploy from more powerful machine <amano>Or, I can wait 3 or 4 days after update. <weary-traveler>amano: you could also modify your channels file to ensure you only get updates when substitutes are available <weary-traveler>don't have the url handy, but you should be able to find it with above <nckx>Important note: that substitutes only ‘guix pull’ *itself*, i.e., the work done by ‘guix pull’, and not even all of that. <nckx>(Please do not respond with a variant of ‘well that sucks’ because *you are right* and *we know it sucks*, that is not the issue.) <apteryx>ACTION tries to install Guix System on an OVH VPS <apteryx>which means, cannibalizing Debian 12 into Guix System <amano>So, what's the best way to make sure that there are substitutes? <Rutherther>Check substitute availability with guix weather Prior to updating chanells. Could be automated with similar manner to what you sent from the manual <nckx>Some variant of my stupid loop above, where you manually poll the substitute server over HTTPS until the substitutes that you need are available. Probably using ‘guix weather’ or parts of it. Emphasis on ‘you’. If there were code in Guix that did this, I'd tell you, pinky swear. <nckx>I need to go back to typing fast school. <nckx>Where you learn to type fast. <nckx>Or faster than Rutherther at least. <nckx>As a large language model, I don't strictly type per se, but interface directly with the neurons of my host organism in a crude parody of life itself. <nckx>rhuijzer: Shouldn't be overly so if you pass specific package specs on the command line. <nckx>Mind you, I wish it were faster too. <amano>If I'm going to buy a laptop for guix, I better have 32GB at least. <dariqq>What can i do if i have conflicting gtk packages (gtk+@2 and gtk+@3) propagated into my home environment? <Rutherther>Why do you have them propagated in the first place? <rhuijzer>amano: 32GB ram ? I'm doing fine with 8GB <dariqq>gtk3 is from nm-applet and gtk2 from pidgin <nckx>ACTION jumps up, reconsiders, quietly puts away the ‘welcome to why why propagation sucks’ slide deck and dance routine costumes. <amano>rhuijzer: Do you build qtwebkit on SSD? <amano>building qtwebkit will probably require more than 8GB. <nckx>dariqq: I'm afraid that your options are limited to ones that result in gtk@2 and @3 not ending up in the same profile, full stop. <nckx>No avoiding that so don't try to. <rhuijzer>amano yeah true. I haven't build qtwebkit tho <amano>Arch linux with AUR is cumbersome, but it at least updates fast..... <amano>It updates fast on a low-resource machine. <Rutherther>dariqq okay, unfortunately I am not knowledgeable enough to say why these propagations would be needed. You could try making a package that will symlink only stuff you need from those packages (like bin folder desktop files etc). But I am not sure if the apps will misbehave. <dariqq>Hmm i have replaced pidgin with a variant that moves its propagted inputs (gtk2 and glib) to inputs. And pidgin still seems to work. It seems to be already wrapped with GTK_PATH and GIO_EXTRA_MODULES. Maybe this is a relict of the past and no longer necesarry? <dariqq>ACTION wonders how many pacakges propagate gtk/glib <apteryx>dariqq: could be! unless it's intended to be used as a library, but this is a GUI IIRC <dariqq>apteryx: hmm the pidgin and libpurple pkgconfig files require glib and gtk2 , so i think propagating is correct <apteryx>for pidgin, unless it's used by something else... it may be best to not propagate <dariqq>i am not sure if the various pidgin plugins need only libpurple or also the pidgin library. <dariqq>There is also finch.pc which wants libgnt (which is not propagated by pidgin) <dariqq>kind of annoying when something doubles as a library and application <apteryx>unless you can test that all plugins still work when not propagating, it may be best to leave it as-is then <dariqq>i guess ill just stick with a variant that does not propagate things for my home environment <Kabouik>I am trying to update the `remind` package (we're two full versions behind) but the existing definition uses (rename-file) and I can't make it work even if I re-use all use-modules from Guix main channel's calendar.scm (where old remind already is). What do I need to import to use rename-file? And shouldn't it work out of the box if I already copied all the use-modules from the calendar.scm? <Kabouik>Wait, I believe it was just an issue with my define-module. Sorry. <Kabouik>Nope, I'm wrong, the rename-file issue persists. <dissoc>how do i separate system configurations into multiple files? for example, i might have shared firewall rules that multiple configurations share <jaft_r>Kabouik: I'm pretty certain "rename-file" is a Guile functionality and doesn't require use any particular module for it to be available (popping open a Guile REPL immediately has it available for use). What's the error you're running into? <dissoc>ieure: gotcha, it seemed like whatever i tried to do it could never find the shared file. but i also dont really know guile very well. <Kabouik>jaft_r: thank you, then I think it comes again from my broken way to try upgrading packages by starting from individual package.scm files in my private Guix channel, which I know is flawed and suboptimal, but I'm always frightened at pulling the official Guix git repo when I have commits submitted as patches that have not been merged yet, my git workflow being what it is, I always fear I'll get confused and lose my previous work. <ieure>mgd, Please fix your client, it's spamming the channel with disconnect/reconnect messages. <dissoc>ieure: i couldnt even get (load "file.scm") to work. but i guess putting it in a channel would make it accessible <ieure>dissoc, Channel is the least annoying way to do this IMO. <ieure>Can someone temp ban mgd or something? <nckx>The ‘ban’ expires in 3 days. <jaft_r>Kabouik: I get it; I tend to do the same thing, though with individual files saved in a directory in my home directory. <nutcase>Dear beloved Guix, a "guix pull" gives me segfault. What could be the reason? <ieure>nutcase, Hard to say. Could be bad RAM, could be a bug in a C library used from Guile. <ieure>Those are the two most likely IMO. <nutcase>ieure: any advice how to find the actual cause and how to solve a potential library issue? I only have the current and (fortunately) one previous generation available. <nutcase>if the issue already existed in the previous generation. It's unlikely that a library issue is the reason. Because: If a library issue was the reason, I wouldn't have been able to create the current generation, right? <ieure>ltrace gives you a bit clearer view into what's happening, or you could run `guix pull' under gdb to get a stack trace / core dump. <ieure>strace is low-level, but it looks like the issue is with TLS certificate handling. <nutcase>ltrace gives me ""/home/flake/.config/guix/current/bin/guix" is not an ELF file" <nutcase>both generations I have, give me a segault for a "guix pull" or "sudo guix system reconfigure ..." :-( <Rutherther>is there anything else apart from a segfault before it? <Rutherther>what about guix shell, build commands? probably good to try both with something you have in the store already and without <nutcase>earlier this day, I was able to run a "sudo guix reconfigure" and I aborted it, since it tried to build icedove. Now, with the same system generation, a "sudo guix reconfigure" segfaults before it starts trying to build icedove. <nutcase>"guix build icedove" starts building icedove <nutcase>it seems that both, "guix pull" and a "system reconfigure", segfault during or immediately after an "Updating channel 'guix' ....". So some SSL issue seems to make more sense to me <umanwizard>Hello, how do I install a version of guix that is built from source? I already know how to build it and then use it via ./pre-inst-env , but I can't find any documentation on how to install it as my profile default guix <nckx>I recommend using ‘guix pull’ as normal but with a channels.scm that uses (channel (name 'guix) (url "file:///home/umanwizard/guix") …)). Note that uncommitted changes will not be visible. <nckx>Is there an idiomatic way to combine two build systems in a single package, such that keywords from both build system are respected? In this case, I'm talking about cargo-'s #:cargo-inputs &c. and gnu-'s #:make-flags &c. <umanwizard>nckx: Thanks. I didn't realize you could use file URLs there. <nckx>You'll want to keep using ./pre-inst-env for fast iteration though, ‘guix pull’ will be its usual zippy self… <esnos>Hi, do you like guix home? Or just put everything in config.scm and uses gnu stow? <amano>Let's assume that program A depends on library B. If I make a few modifications to B, does A fail to depend on B? <amano>Is it possible to override B in a way that A can still depend on B? <ieure>amano, Do you have a concrete example? <amano>Let's say that I just added a few lines to a file in B. <ieure>amano, The change in library B's package definition will result in program A being rebuilt. <ieure>What do you believe "override" to mean? <ieure>Nothing is being "overridden." <amano>I worried that if I modified B, I had to create a new definition of A that depends on the modified B. <ieure>Again, a concrete example would be extremely helpful. <amano>There is no concrete example, yet. <ieure>If both A and B are defined in the same channel, and your changes to B are committed to that channel, Guix will notice that A's inputs have changed and rebuild it. <amano>That's just the kind of thing I do often in gentoo linux. <ieure>I am not sure this is the question you're asking. <amano>I just wanted to avoid rewriting definitions of all dependent packages. <ieure>If Guix ships with program-a and library-b, and you want to change the definition of B without pushing commits to Guix, that is a different kettle of fish. <amano>I want to modify B locally in my own channel for A which resides in the official guix channel. <ieure>amano, You'll have to change the definition of A in that case. You can do that by inheriting A and rewriting its inputs to point to your local fork of B. <amano>If I inherit B in the official guix channel, do I have to inherit A, too? <amano>I want to offer a modified version of B. <amano>But, I want the modified version to override the original. <amano>So that A depends on the modified B. <ieure>Guix doesn't really work like that. Package dependencies are resolved at build time. <amano>I don't know whether a package definition depends on guile symbols or program versions.... <ieure>The only way to change an input (dependency) of package A is by rewriting its definition. <ieure>singpolyma, Yes, I know, keeping things simple. 