<mekeor[m]><patched[m]> "Is there a neat way to only..." <- maybe you could use the root user's guix to run guix-system commands and have your custom channel included only in the root-user's profile? ***Xenguy_ is now known as Xenguy
<luke-jr>is there a reason guix doesn't use libfaketime to ensure builds use deterministic clock readings? <raghavgururajan>Aleci[m]: I see. I am out of ideas. Could you try swapping gdm with sddm? Just to check if the issue appears only with gdm. <guixsd-n00b>does anybody knows what package I've to install so I can 'man mprotect' and others linux api manuals? <apteryx>luke-jr: it doesn't need to in most cases, with build tools honoring SOURCE_EPOCH_DATE <apteryx>but I think it does in one case, when TLS certificates validity would otherwise expire after a while and fail the test <luke-jr>apteryx: and the recent libgit2 issue <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 <PotentialUser-42>Thats the definition of my package. As you can see I use ssh style git-reference. Is this even allowed? <abrenon>I think I've always seen public HTTP urls in origins' URLs <abrenon>ok it's obviously not working but what I don't understand is the "could not read Username" <abrenon>did you by any chance forget to replace the ':' (semicolon) by a / when changing the scheme from git to http ? <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>abrenon right now change the package inside the channel and run guix pull again <PotentialUser-42>When testing an own channel it takes a little long always pulling the default guix channel too <abrenon>there's --channels but I'm not sure it works for that <abrenon>anyway, you're better off simply working on the package locally on a file and making sure it builds before publishing it to your channel <mekeor[m]>while developing on a file within your channel, you could also build the package from file <abrenon>channels are for clean distribution, not for hacking <abrenon>there's no reason it shouldn't work with your locally-hosted instance <mekeor[m]>you can also clone/pull your private repo to a local dir and use file:// <mekeor[m]>well, actually iirc you dont need to type file://, but just use the path <abrenon>you said your channel was created successfully so I think we can assume it works and it's not the source of the issue <abrenon>AFAIU you only need to fix your package declaration <PotentialUser-42>abrenon I made the git project public and I got further down the road. Now the build phase of the python-build-system fails. But checkout and unpack works. <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? <nckx>I don't even speak Swedish. <nckx>You're welcome. GitLab's very irritatingly turns any 404 into a 200 that means ‘permission denied’ so is doubly wrong. <nckx>It's just time for a new release 😉 <abrenon>PotentialUser-42: no I can't make it "cloneable" this is the lab's gitlab instance and I wasn't suggesting you clone it, merely pointing at a guix package description <nckx>abrenon: So I was wrong? <abrenon>hmm you at least misunderstood my attempt : ) <abrenon>it wasn't moved, you merely pointed to the root of the project, while I was pointing at a particular file <abrenon>but is the first link I pasted broken ? I copied it directly from my navigation bar <abrenon>the home-page is inaccurate because I was thinking about moving the repos at some point <abrenon>to pyedda but then my advisor got mixed feelings about this in there is still a lot of cleaning to do on the source it currently contains, probably separating parts to a different repos but <abrenon>anyway it wasn't my point: I was just saying "hey, it's very easy to package a project with a simple setup.cfg file, look I did it there" <nckx>It's nice to know there's no missing ‘proprietary’ magic though. <PotentialUser-42>abrenon I finally got it. I now use a simple setup.py file only. All the mess with pyproject.toml setuptools-scm etc. was superfluous. <abrenon>yeah, with a simple pip structure it's really easy to generate packages for guix <PotentialUser-42>I am far no packaging expert but there are so many PEP which want to change/improve packaging. <abrenon>oh are there talks about deprecating that structure ? I didn't know about that <PotentialUser-42>And while installing I get: Using legacy 'setup.py install' for AmmosReader, since package 'wheel' is not installed. <tricon>What kind of hardware is the Guix team looking for re: donations? Is there a list somewhere? <nckx>I'm not aware of a wish list (that's a good question, really). aarch64 and riscv64 (*if* that's economical at this point) I'd say. I suggest mailing guix-devel at gnu dot org with that question. <nckx>Oh, and powerpc64 with the same parenthesis. <nckx>‘Everything but x86_64’ correct :) <tricon>nckx: Excellent, thanks for the info! <nckx>Thank you for the offer! <abrenon>ahh, I see, thanks for the link to the issue nckx <tricon>Certainly. Always happy to help "the cause" if I can. <nckx>I can't say much more than hur hur issue link hur because I don't really understand Python :) <abrenon>well about time python packaging improved, too bad they didn't migrate to something good like guix <abrenon>but I suppose we'll have to reimplement a new-python-build-system <nckx>If they take this ‘API’ stuff seriously it could be an improvement over ‘observe what setuptools does’. <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>As in I was surprised at how thin it was. <nckx>So yeah, something like that. <apteryx>abrenon tox is mostly useful to isolate the build/test environment from the host, which Guix already does when building a package, so it's useless <abrenon>oh, really ? so that's already infinitely more information that what I could find <apteryx>so usually what you should do I find out which test runner is used and how it's launched (typically: pytest), and use that directly <nckx>I did that, but I didn't understand why at the time. Thanks for explaining. <abrenon>I was just desperate trying to find what it ran and couldn't even find that <apteryx>also, on Guix, tox is currently a bit broken as the GUIX_PYTHONPATH finds its way in the supposedly isolated environment :-D <abrenon>but anyway, yeah, instant dislike of the thing when I found out about it <apteryx>I think because tox only clears/manage PYTHONPATH, not GUIX_PYTHONPATH; that should be fixable if someone wants to do that <abrenon>you mean to use it userspace ? because yeah, for packaging I agree with you, I cannot see how it could be even remotely useful <apteryx>yeah, if you were to use it in a project of yours, outside of packaging <apteryx>it can be useful to run the tests against various versions of Python (e.g., 3.9, 3.10, 3.11) <abrenon>not a chance : ) but thanks a lot for the tip ! <abrenon>I'm staying away from that inferno, I just hope we'll have the python build system able to handle that someday <nckx>> you mean to use it userspace <nckx>What's the Gexpy way to (re)write (assoc-ref [%build-]inputs "foo")? <nckx>Or rather, the input-labelless way. <nckx>abrenon: Yeh, that was too silly. <apteryx>To add to the confusion/joke, there's already a Guix "kernel" for Jupyter ;-) <abrenon>(seriously though, that was a bad choice of word sorry, but I'm at a loss for a better term) <bjc>nckx: does #$foo not work? <jpoiret>#$(assoc-ref (package-inputs this-package) "foo")? <jpoiret>for build inputs, i think the dance is a bit more technical <bjc>i'm confused again: what's the difference between: #$(assoc-ref (package-inputs this-package) "foo"), #$(assoc-ref inputs "foo"), and #$foo? <jpoiret>the 1 and 2 are equivalent if you've declared the inputs before that part, otherwise you can't refer to inputs <jpoiret>and the third will just give you the result of ungexp'ing the symbol foo, whereas the 1st and 2nd lookup which foo is actually declared as an input <jpoiret>the logic for the 1st and 2nd is that if you replace a library with a drop-in replacement, you don't have to modify the code at all <nckx>Hmm, I thought I'd tried the obvious package-inputs this-package… 😛 <bjc>ungexping ‘foo’ when its declared as an input doesn't return the input? <nckx>Did I screw it up? Always possible! <jpoiret>nckx: off the top of my head though, and coming from someone who almost never touches packages <nckx>bjc: So I avoid #$foo, although I've written it. <jpoiret>there are no "named g-exps inputs" although it could be useful <bjc>is it just that it happens to work, because by declaring an input you're automatically pulling the symbol into the build environment? <nckx>jpoiret: Still, I give it another go and will double-check for typos (I swear I have #$-based dyslexia…) <nckx>bjc: Well, not quite ‘happens’: it works by design (for the reason you give) but that also makes it inflexible (e.g., no --with-transformations AIUI). <jpoiret>bjc: right, when lowering the g-exp the derivation will refer to that <jpoiret>also you lose the ability to query dependency trees <nckx><no transformations> …and worse, for me, unexpected naive inheritance. <jpoiret>but, `guix size` and friends should still report the dependency when the output is built <bjc>ok, i was under the assumption that #$foo was the preferred way to do things <bjc>looks like i have a patch to resubmit... <nckx>‘#$foo refers to (inputs foo)’ would be an interesting semantic, but I fear it's too ‘weird’ from a purely lexical perspective. It would look like regular Scheme code but act differently. <bjc>for referring to outputs, though, i should still be using #$output and #$output:foo, right? <jpoiret>although, you could say the same about #$output <nckx>bjc: I'm not entirely sure the matter is settled or there are great solutions to every use case, at this point, to be honest. <nckx>I think #$foo is currently unavoidable sometimes. <bjc>well maybe i'll leave it as is and wait for maxime to complain, then ;) <nckx>I'd love to be proven wrong. <bjc>i liked the #$foo, syntax-wise, although i can see the confusion now. it was just terse and didn't require extra let bindings if you were going to use it a lot <nckx>jpoiret: Good counterpoint, to which I can only say there's (normally) no global output variable with which to confuse it, but that's a terrible argument. <jpoiret>nckx: note though that with the new input style, the 1st and 2nd syntaxes above won't work with replacements :p <nckx>Muh, I don't use replacements. Can't I just ignore them? /s <apteryx>bjc: does the #$output:foo syntax currently works in a package? <jpoiret>canonically, what the new style does is (match p) ((package? p) (list (package-name p) p) <nckx>That's an implementation detail, though. <jpoiret>right, but it matters when assoc-ref'ing <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. <nckx>The good ol' 3-fold duality. <bjc>here's another one i don't quite get: in the xfstests package, within lines of each other, there's a (string-append … (assoc-ref inputs "bash") …) and a (search-input-files inputs …) <bjc>i'm not sure where to use one vs the other, and it seems like all cases in that package could have been (search-input-files) to me <nckx>Pretty sure I wrote xfstests before s-i-f was a thing. <bjc>the confusing thing is that it uses both, and right next to each other =) <nckx>gnu: Use 'search-input-file' when looking for executables.bc (64d9554b337d4baaeccbcce22ea08a184c9e4c) <nckx>If that wasn't an automated commit, is was still only searching for a specific pattern, and ignoring other possible s-i-f possibilities. <nckx>*as opposed to impossible possibilities, which are not possible. <bjc>ok, that makes sense. it didn't occur to me that it might have been an automatic conversion <nckx>For Ludo's sake I hope it was. <bjc>certainly the bash/sh match is more complex than the others <civodul>nckx: do you think we need an update regarding the "gexp migration"? <nckx>What kind of update? Prose? I'd certainly benefit from that, but I also can't write it 😉 <nckx>It's been a while since I read that, I'll do so again. <apteryx>the guix-substitute crash has been fixed, right? <civodul>there's been a few cases since then where we weren't sure what idiom to use <civodul>apteryx: what's "the guix-substitute crash"? :-) <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 <nckx>So I'm clearly missing the big picture. <civodul>nckx: here'd i'd write (ungexp (this-package-input "bash") "include") <civodul>it's not as pretty/clear than the default "out" case <nckx>OK. I think it did work (thanks!) but it looked so fragile I thought surely it must be wrong. <nckx>I tried a few such things and they all felt… off. <nckx>OK, I think it's just cognitive dissonance because of how elegant Gexps *can* feel and then suddenly, whoomp, …this. <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 <apteryx>uh, I just got: guix build: error: corrupt input while restoring archive from #<closed: file 7fb7ac95e1c0> <jackhill>jpoiret: yes, it's been intermittent. When I notice it getting stuck, I CTRL-C and try whatever I was doing again. Eventually it works. <bjc>civodul, nckx: am i understanding right that you'd change the line to: (assoc-ref %build-inputs (ungexp (this-package-input "bash") "include"))? <bjc>or should the entire assoc-ref be replaced by (ungexp …)? <nckx>No, drop the outer (a-r …). Just (ungexp). <apteryx>civodul: good! that'd explain why I'm not seeing backtraces as much today :-) <bjc>ok, that makes sense <jackhill>/run/booted-system/provenance says this is guix 37e44d48baf976f6bfcd885b2e10da4ab7be4af9 (I think that's the commit my deamon is from) <bjc>would (search-input-files %build-inputs "/include/bash") work here? <civodul>i installed Guix System from a current-ish installer today and it's been a complete disaster :-) <civodul>now i can't log into GNOME for some reason <jpoiret>i just looked at the root account thing <jpoiret>adding root through (operating-system-users ...) isn't supported right? <civodul>jpoiret: that one is most likely the aftermath of a recent bug fix <jpoiret>the root account code has been there for 3 years though <jpoiret>mathieu only added a check that one would not create a root account through the gui <apteryx>oh, interleaved responses. That probably explain other crashes I had reported. <civodul>but "something" is adding (user-account ... "root" ...) to the config <jpoiret>oh yeah, it's been there for all that time <jpoiret>i think the issue is that we're not setting (uid 0) for it <jpoiret>so guix system adds another root account <jpoiret>civodul: i'll see if i can reproduce <nckx>bjc: No, but. Ugh. search-input-file means search-input-regular-file 🤦 Why… Anyway, search-input-directory works. <bjc>is it actually an alias for s-i-r-f, or does it do extra stuff? <apteryx>does icecat really still require python 2? *apteryx adds to python 2 cleanup stack <jpoiret>well, i don't have internet at home right now and downloading 222MBs of substitutes doesn't seem like a great idea <nckx>That's a lot of floppies. <nckx>bjc: There is no s-i-r-f, s-i-f wraps search-path which doesn't work with directories. Directories are files. <bjc>rob pike is very disappoint <nckx>‘In Unix, everything is a file, except the things that have all your files in them, don't be silly, the world isn't ready for that.’ *nckx Bill Gates hands rob a tenner under the table. <nckx>Not sure why I didn't capitalise rob. Please do not search for meaning where there is none. <bjc>don't worry, i never capitalize rob either <nckx>Search volume for ‘rob pike original username’ peaks. <nckx>Oooh. (native-inputs (list `(,bash "include"))) breaks everything. <nckx>command "/gnu/store/6pmcqvf8m8hj0whrir1rknismi0an8ck-bash-5.1.8-include/bin/bash" "./configure" … failed with status 127 <dirtcastle>I'm trying to install guix distro in another partition from ubuntu. guix package manager is installed in ubuntu. trying to install it using guix system init <dirtcastle> I need to run this command but shepherd only comes with the iso and not guix right. what should I do now. <nckx>It's only needed and meaningful in the installer ISO, which runs from limited RAM. You're not running from RAM so don't need an overlayfs. <bjc>i like the idea of multiple outputs for a package, but the implementation often feel very clumsy to use to me <nckx>(The ‘cow’ is for copy-on-write, meaning that anything written to the /gnu/store in RAM will actually write to a hidden directory in /mnt, so your RAM doesn't fill up and die.) <nckx>Hm, I almost quoted the manual verbatim, I didn't know :) Sorry. <civodul>jpoiret: FWIW, the GNOME issue i have is GDM failing with: "GdmDisplay: Session never registered, failing" <bjc>civodul: is gdm starting for you at all? <civodul>bjc: yes, but when i attempt log in, GNOME doesn't actually start and i'm back at the login screen <bjc>ah, it doesn't even start for me. locks up my console completely <bjc>i haven't really poked at it to see what's up since i only really use guix over ssh at the moment <civodul>on top of the various bugs, ci.guix appears to be flaky today <civodul>not a good day for a system install :-) <vagrantc>it's pretty much what it's like for aarch64 everyday :) <civodul>i spent a fair part of the day trying to complete a basic system installation with GNOME on x86_64 <rekado>civodul: apparently there were some network problems <rekado>at 2pm I received an email that stated that “The network interruptions could be resolved. Further interruptions are not to be expected.” <civodul>i think Cuirass didn't build recent things, too; not sure if that's related <rekado>efraim: I see that you fixed some breakage that my minor-verson updates of some Rust packages have caused. Thank you. <rekado>is there a way to avoid this breakage in the first place? <rekado>since “guix refresh -l” doesn’t help here I find it very daunting to touch any Rust stuff. <rekado>I have two more minor updates, but I don’t want to break stuff. <rekado>rust-syn-1: Update from 1.0.82 to 1.0.92; and rust-unicode-xid-0.2 from 0.2.1 to 0.2.3. <dlowe>I have a question about substitutions - `guix weather firefox` lists 0 available substitutions, but it also says that there are 23.82 builds per hour. I'm having trouble reconciling this. <nckx>Just ‘builds’ general, not Firefox builds. <nckx>23.82 Firefoxes an hour is a lot. <dlowe>I figured it was highly parallel builds :) <nckx>Berlin could handle a lot more than 24 FF/h but alas, it does not build Firefoxen, only IceCats. <dlowe>need a guix-substitutes@home project :p <bjc>i wonder if you could generate consensus by having a blessed builder that only runs if the @home builders generate a conflict <civodul>rekado: what i did was compare with the output of "guix import crates xyz@1.2.3" <civodul>that way you can see whether inputs need to be changed <dlowe>bjc: that seems like a reasonable compromise <civodul>and yes, Rust packages look like a time bomb, kinda out of control :-/ <bjc>my recollection is that "syn", in particular, is at the bottom of a lot of dependency graphs <dlowe>civodul: could that be helped by a dynamically generated rust-cargo channel? <dlowe>is there a way to keep from building when using guix upgrade? <dlowe>it was surprising today when I went to upgrade firefox and it started downloading the rust toolchain <AceTheMercenary[>Building usually happens when the source code is more recent than the substitute <dlowe>right. guix pull updated the definition, there's no substitute ready. I understand that bit. <dirtcastle>i need some config file to run guix system init it seems. where can I get that file. <jpoiret>Only Gold Tier GuixOS Supporters™️ get access to this *special* file <jpoiret>Jokes aside, you write it by hand, there should be an example at /run/current-system/config.scm (or configuration.scm) <jpoiret>There's a whole section in the manual that describes this <jpoiret>Arf, you're not on the install image are you? There won't be an example where i pointed to the <dirtcastle>jpoiret: yeah I don't use installation image. that's the problem. or else there are steps to do it in manual already <dlowe>(no IceCat substitutes either :p) <civodul>the one other issue i noticed is elogind: the race between shepherd and dbus trying to start it is a complete mess (again) <civodul>probably became worse with shepherd 0.9.0 <civodul>we just shouldn't rely on the PID file for notification <lilyp>dirtcastle: there are some templates in the git checkout <jpoiret>Yes, i've been experiencing that myself on my own system <lilyp>they're the same as for the installation image <jpoiret>iirc the pid file in elogind should be ok, i think there might juste be some services with missing requurements <lilyp>otehr than that if you're running guix system already, there should be one stored in a well-known location, as well as possibly in the store (for the latter see guix system describe) <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 ;) <the_tubular>Umm, could you point me towards it, I want to read on this <unmatched-paren>which then compiles a slightly more advanced hex assembler that supports macros <nckx>Much, much comes before the first C compiler. <dlowe>it used to be a popular manner of entering programs from computer magazines :D <civodul>the GNOME login issue is not reproducible in "./pre-inst-env guix system vm gnu/system/examples/desktop.tmpl" :-/ <nckx>(That page also says 280 bytes, FWIW.) <dlowe>note that hex0 can read its own source to see if it produces hex0 <unmatched-paren>then we get a tiny C compiler once we have a sufficiently advanced hex macro assembler <unmatched-paren>we use that to build m2, which is more advanced and written in the hex cc's dialect <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>the_tubular: search up "parsing c++" and "c++ templates turing completeness" <unmatched-paren>the_tubular: of course, we have a couple other problems after C++, like java and rust <dlowe>c++ templates turing completeness doesn't bother me. Unhygienic lisp macros also are turing complete. <the_tubular>Yeah, I guix pulled yesterday and pulled like hundreds of crates <bjc>i had over 1000 for a home reconfigure of 20 packages <dlowe>the_tubular: it's trying to build firefox or icecat probably <dlowe>they just had a release drop and there's no substitute yet <bjc>dlowe: i don't have icecat or firefox <dlowe>pretty sure that's what triggered it for me <bjc>i have ripgrep and alacritty <bjc>so yeah, 1000 crates makes sense for a grep replacement and terminal emulator. rust is a good environment that makes sane packaging decisions <unmatched-paren>bjc: apparently the ripgrep author tries to reduce the amount of dependencies they use. **apparently**. <bjc>i haven't actually checked to see what the culprit was. it might have been something else not explicitly rust that gained a rust dependency, too <bjc>but still, it's obviously an insane situation no matter how you slice it <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 <bjc>yeah, i often have to use it outside of git. and it's fast enough compared to git grep that i use it there, too, just for muscle memory <bjc>maybe; like i said, i haven't checked. i've been meaning to, since i'm hoping there's something fixable here, but i haven't gotten around to it <the_tubular>I wish guix was a bit more verbose though. X has caused Y to rebuild. <dlowe>there was a bug to add a --please-don't-build flag but it was closed in favor of being able to make a weird kind of channel <apteryx>civodul: ah, "GdmDisplay: Session never registered, failing" <Christoph[m]><bjc> "it works better for me than find..." <- `grep` has an option to recurse through subdirectories. That is faster than find + grep, too. <dlowe>I was going to say that, but they probably wanted to find specific files <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? 🤔 ***lukedashjr is now known as luke-jr
***reyman is now known as reyman_aw
***reyman_aw is now known as reyman
<zacchae[m]>is shepherd the easiest way to have a one-shot command executed at startup? <unmatched-paren>funny how all these 'malicious dependency' problems that i hear about are all javascript-related... anyone know of any similar incident with other ecosystems? <dlowe>it's a cultural thing with npm <dlowe>there's almost no barrier to submission and a high degree of interdependency <lechner>Hi, does anyone have Kerberos or NFSv4 working? <bjc>unmatched-paren: i'm like 98% certain crates.io has some lurking, but they haven't been found yet <bjc>there's no real cultural difference between what rust is doing and what npm does <bjc>i did not see that coming <bjc>if this opens the door to virtualized drivers i'm going to be very happy <bjc>i wonder if they've found a way to use the gpl and still put binary blobs into the source <dlowe>the user-level drivers are still blobs <dlowe>this just covers the kernel modules <dlowe>I think this really improves the prospects for nouveau though <bjc>looks like gplv2 only. i guess just so it can be directly linked with the kernel <drakonis>i think they were working on it since circa last year <drakonis>there's a tweet from daniel vetter that alludes to nvidia <littlebo1eep>great now make it so we can post more than 140 characters at once <bjc>ok, you can now do 280 <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. <maximed>civodul, nckx: For the bash case, in the past I've proposed things like (dirname (search-input-directory inputs "include/bash")) <maximed>Maybe we can have (search-input-directory inputs "include" #:contains-directory "bash") <maximed>because otherwise we add "bash" just to remove it later <nckx>I don't think that improves anything. <nckx>Just use dirname, if needed. <maximed>I don't really care much about this, just seemed like something people might care about <nckx>Personally, I'd just teach such persons about dirname & call it a day :) <maximed>I proposed the '(dirname ...)' once though the patch submitter didn't include it. I don't remember the reasons. <nckx>The package I used as an example above (recutils, I think?) actually happily consumes include/bash, no string munging needed. <maximed>I don't see why recutils wants --with-bash-headers in the first place given that 'bash' doesn't end up in the references though <nckx>Build it without & see :) <nckx>I didn't investigate what exactly happens. <maximed>now doing ‘guix build recutils --target=aarch64-linux-gnu’ <maximed>cross-compiling because native-inputs and lack of 'bash:NON-INCLUDE' seems suspicious <maximed>Looks like every dependency of cross-recutils was substitutable, nice <nckx>Anyway, the --with-bash-headers controls the building of some extra libraries. readrec? from memory. <nckx>I might have cheated and run that earlier. <nckx>It's my go-to test as well. <nckx>Amazing the amount of crap that just breaks. <bjc>maximed: out of curiosity, do you get emailed updates to issues you comment on? <bjc>i'm not trying to pressure you into looking at my patches again or anything. but you're so quick on the first patch set it makes me wonder about the subsequent ones <maximed>I usually tend to respond to the first version but less the later ones <bjc>i get the impression most people with commit bit are pretty swamped <maximed>Basically the idea (rationalisation?) is to give people new to Guix a kind of quick introduction of sorts of the kind of things they have to keep in mind <bjc>i definitely appreciate it. there's a lot to learn <maximed>but follow-up to the conclusion is a bit too much of an investment for me <maximed>Also, TBC, I don't have the commit bit <nckx>Almost certainly voluntarily, I should point out. <bjc>i wasn't going to say anything ;) <maximed>#$output:foo or (assoc-ref outputs "foo")? I've seen an argument for the latter based on the ‘Law of Demeter’. *maximed quickly leaves Zzz <bjc>it also doesn't require passing an ‘outputs’ to the build phase procedure <bjc>that may be good or bad <nckx>I'm confused twixt latters and formers now. <bjc>sorry, yes, the former doesn't require it <bjc>the former mrs. dewinter *nckx finds #$output easier to read, do we fight now <singpolyma>Yeah. The former is more concise in several ways, but since when is scheme concise, heh <nckx>And not because of concision. <nckx>drakonis doesn't care about this nitpickery, drakonis is just happy, be a drakonis today. <nckx>Do you have a working GPU? <nckx>I sorely want to believe. <bjc>i used emacs 29 for like 2 days a few weeks ago, and i still miss the emoji selector terribly <drakonis>well, it seems like this time is for real <drakonis>but the biggest win so far is that nouveau can be usable now <bjc>we'll see if they keep up with it. it'd be nice, but megacorps can be fickle <nckx>That scroll bar size implies the extent of my madness. <bjc>hmm. i suppose i could just hand code some expansions <nckx>drakonis: I'm still waiting for you to drop the punchline ‘they opensoresed a wafer-thin GPL shim like everyone else so they don't get linuxed’. <bjc>(and i thought that scroll thumb was just one of those old-school ones that stayed a fixed size... yikes) <drakonis>today's just the kernel drivers, not the userspace bits <drakonis>but on the other hand, that can be used with nouveau to make it not awful <drakonis>the proprietary driver is a gpl shim though <nckx>So CONFIG_DRM_NVIDIA levels of GPL? <nckx>I don't have one but I'm happy to hear it (if pathologically sceptical). <drakonis>right now it is still structured like the proprietary driver *nckx is happy as long as Mesa doesn't retire ‘legacy’ i915 😠 <bjc>i think these drivers are turing+ <nckx>drakonis: Sure, for CONFIG_EXFAT levels of CONFIG_DRM_NVIDIA, of course, for now. <drakonis>the drivers support the previous generations, poorly. <nckx>Closed suck → OpenSuck™ → Open OK I guess. Step 2/3 ain't bad. <drakonis>the highest it advertises as working is turing and ampere <drakonis>it needs features that only works with turing and forward <drakonis>so nouveau it is, but at least it wont be absolute trash <bjc>just get a new gpu. how hard could it possibly be? <ss2>good evening everyone. Do you mind if I ask how I best chroot into a Guix? My grub.cfg is empty for some odd reason, so I'd need to get into that system somehow and try to reconfigure again. <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 <ss2>it is mounted to /mnt/gnu/store now, <ss2>the partition is mounted to /mnt, yes. <nckx>Would that not make it /gnu/store inside the chroot? <ss2>yes, though I'm no guru at chrooting. :) <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? 