<luke-jr>apteryx: seems like just doing it by default would make sense? :p
<apteryx>seems pretty edge case to me; is this done on other systems (nix perhaps?)
<apteryx>but I think our ad-hoc solution is sufficient for now (add it as an input and use it when it's needed).
<reyman>I search some explanation in the doc about different places of channels.scm, i have problems with some chan into channels.scm not recognized with guix home. Running guix home describe doesn't return the content of my .config/guix/channels.scm ; i try to made a symbolic link between .config/guix/channels.scm and /src/guix-config/channels.scm but the result is the same
<reyman>guix home describe, guix system describe return different things ... and channels are missing
<abrenon>yeah, I've seen that, which is why to some extent you'll have to fix the local network errors by yourself, but for the moment what's blocking it is it's unable to retrieve the origin
<abrenon>and I think it may be because your URL is malformed because that Username error is weird (and reminds me of the notation with a username in HTTP URLs, which appear before the hostname separated by a semicolon)
<PotentialUser-42>Python packaging is a pain. I use pyproject.toml setup.cfg and setuptools-scm. Now I have to bring the version information into the right form. Is there anybody here who packaged his own python software with guix?
<abrenon>I once stumbled upon a package using a thing called tox for tests
<nckx>Oh… I've encountered a good few of those? To the point that I didn't know it was (apparently) obscure/old?
<abrenon>and despite all the documentation I crawled, I could never find anything past the "do you know you shouldn't use virtualenv ? actually try this new tool called tox and be enlightened to the right way of setting up environments"
<nckx>Again, my knowledge of Python is (1) I take the cargo to the clearing (2) I build the altar under a full moon (3) package.
<abrenon>to this day I haven't found a single proof that tox is actually doing anything because then I wonder why the description of what it does would remain so elusive
<nckx>IIRC tox is just a very thin wrapper anyway.
<nckx>Certainly. I just mean that assoc-reffing is kicking the tin down the road.
<bjc>semantically it feels better to refer directly to a symbol, rather than assoc-ref with a string key, if you're naming the inputs with a symbol and no string
<nckx>All this: AIUI, I kinda half-followed the whole gexp/input roadmap and am not 100% sure where we are and where it ends.
<bjc>right now the string generated for an input is effectively magic
<nckx>The whole string/symbol duality is straining at the seams, the more it gets exposed (the above stuff, gexps, CLI [name-based] transformations, …). I don't see how it will hold but I don't have an obvious fix.
<nckx>My cope is literally ‘civodul has a plan for all this and will take care of it’ 😛 Not… great.
<jpoiret>jackhill: foreign or guix system? if foreign, what is /usr/bin/guix describe?
<jackhill>jpoiret: guix system, and unfortunatley, I didn't capture the describe information (sorry! I should know better), but it was reconfigured with a contemporary guix to that bug report. (this host also have limited disk, so I usually can't keep old generations around). I'll keep my eyes out to see if the problem recurs, otherwise I'll close the issue in due time.
<nckx>civodul: Answer at your leisure, but what I'd like to know (or confirmed) is: is the new (labelless + gexp + this-package, search-input-file, etc.) style ‘complete’? Can all of Guix be rewritten in it in a way that doesn't break, say, --with-input? That's an example of Guix functionality I never use, so I'm always nervous of breaking it. That's just an example though, to illustrate my general unease :)
<jpoiret>jackhill: new guix, but what about its guix daemon (ie did you upgrade the system recently or not)?
<jackhill>yep, the system had been upgraded recently
<jpoiret>jackhill: let's try some manual things, first, type `guix substitute --substitute` and it'll wait for input, you can type `substitute /gnu/store/m6gaq582x4k0ajx9x7hznmw6a4dkg4m4-soundconverter-3.0.2 /tmp/test.nar` and press RETURN, then Ctrl-D (EOF) when it finishes
<dirtcastle>i discovered this bootstrapping. is that to install the os from a binary?
<peterpolidoro>I am trying to create a python package, but the tests fail saying that qt.qpa.xcb could not connect to display. Is there a way to fix this or should i just disable the tests that fail?
<nckx>dirtcastle: It's about how the entire Guix package is actually built, from source, whilst relying on as few precompiled binaries as possible (say: how do we compile GCC without GCC or another huge C compiler binary blob? it's possible, but hard). Most distributions just use a previous binary installation of themselves to build the next version, forever. Guix does things differently, with a known set of bootstrap binaries that it tries to keep very small (and
<nckx>Eventually Guix should build entirely from ‘source’, without any precompiled binaries at all, although the very first ‘source’ file will look a lot like binary gobbledigook, it is very short and can still be audited by experts.
<bjc>the blob is down to, what? 370 bytes or something now?
<nckx>That's my poor explanation of things. See #bootstrappable if this interests you, or just enjoy the results.
<bjc>that's theoretically something you could disassemble and inspect by hand as a single person
<nckx>I don't know the exact count right now but something like that.
<nckx>Ugh: s/the entire Guix package is actually built/the entire Guix package *collection* is actually built/ — so, the entire tree, from the root up.
<bjc>honestly, it's so impressive they got it down so low. almost impressive enough to make me want to disassemble it and read it ;)
<unmatched-paren>then we have a couple of loops of building musl libc and tinycc again several times
<the_tubular>"Additionally, all code must be able to be understood by 70% of the population of programmers."
<unmatched-paren>we build perl (for autotools) which is a bit of a pain because some generated files in the perl dist are generated by perl
<nckx>One of the proposed methods to kick off the bootstrap was to pass the first bytes to the CPU using dip switches, paper tape, etc. No idea if anyone has actually done so, but it illustrates the depth of the problem and the ambition of the solution.
<unmatched-paren>eventually we get to some gcc 4.7 release, which is the last one before they added c++ to the codebase
<nckx>the_tubular: Yeah, I was going to amend my ‘experts’ statement above and didn't. You caught me :) The aim is to bring the level of ‘expert’ down, of course there are ‘experts’ who can disassemble any binary right now.
<the_tubular>So their are key gcc versions that you will always need to stop for and build ?
<unmatched-paren>if you're grepping a git repo (a common scenario) you can use `git grep` which i think is miles faster than gnu grep
<bjc>it works better for me than find + grep. it omits results i almost never care about, it's incredibly fast, and it's one command rather than having to invoke two and having to worry about things like null termination, quoting, and the like
<andi-[m]>Is there a guix thingy that I can point at an OpenStack API, AWS, Hetzner, ... to create machines similar to how this (was supposed to) work[s] with nixops?
<patched[m]>`guix weather telegram-desktop` says that bordeaux has a substitute. Yet, when I do `guix install telegram-desktop`, it tries to build it. Why is this/how can I force it to just get the subsitute and not start building stuff
<patched[m]>My computer doesn't have the ram to build that program
<dlowe>lol, this is really a recurring problem today
<dlowe>patched[m]: try doing `guix pull` first - you may be trying to pull a version for which a substitute isn't available
<patched[m]>unmatched-paren tried that, still wants to build
<dlowe>honestly it looks like the build servers are really overloaded
<patched[m]>dlowe can I easily roll back if I try doing that? Pulled yesterday and have been waiting since then for this program to get built, don't want to have to wait another day :^)
<dlowe>>1k queued builds, 22.65 builds an hour, so at least two days or so before it catches up
*bjc idly wonders if the build servers being overloaded is related to a rust package being updated
<dlowe>I wonder how many build@home matches is reasonable before accepting a package build.
<bjc>my concern with any consensus solution is the ability of an opponent to manipulate the outcome. the current situation has the agreeable (to me) property that its hosted by the same organization that creates the distribution; so it leverages exsting trust
<bjc>the size of any build pool for guix is going to be small, and it will be easy for even moderately sized opponents to overwhelm, most likely. and the output of the system is very valuable
<dlowe>The rust ecosystem is already doing that :p
<dlowe>but yes, I agree with you for the most part, except that I still want to think about how it made be made to safely work
<bjc>the rust ecosystem is already wide open to attack given their apparent love of dependencies
<bjc>i strongly suspect there's no one right answer, and it's all going to involve the tradeoffs you're willing to make
<lilyp>funnily enough, Guix' efforts in antioxidant might make rust reasonable for the first time in its existence
<bjc>lilyp: i really hope so. i'm looking forward to trying it once i get through some other projects
<patched[m]><dlowe> "patched: try doing `guix pull..." <- Pulling doesn't solve it, now weather says that bordeaux doesn't have it. It says that one substitute is available, shouldn't it just be able to download that then? 🤔
<apteryx>could extracting a 'guix pack -S /bin=bin hello' or 'guix pack -S /bin/hello=bin=hello hello' guix pack cause /bin to be completely overriden (e.g., break the system by leaving PATH mostly empty) ?
<apteryx>seems I had that experience just now, eh. The host was using busybox tar, perhaps that has to do with it.
<ss2>chrooting to /mnt /bin/sh fails since the link is to the store which is at a different spot now. Does the installer actually provide easy facilities to chroot from there? I've booted a gparted live at the moment.
<nckx>The installer doesn't have any helpers that gparted live wouldn't have.
<nckx>I don't understand why the store would be at a ‘different spot’, though. Surely it's at /gnu/store.
<nckx>Then again, what can I test: ~ λ sudo chroot /mnt /bin/sh
<bjc>why do you need to chroot at all? all the grub stuff should be available without it
<ss2>tbh, I can't be sure what went wrong. I reconfigured, tried to reboot and the system crashed while throwing errors writing to a partition. I fscked the partitions. They're all fine. But something went wrong since some file like grub.cfg are empty.
<nckx>ss2: Then I don't understand the ‘different spot’ problem, if it exists, but also I'm currently distracted by the fact that chrooting /bin/sh on 2 Guix Systems segfaults on me. What happens to you?