<cocomeat4[m]>Which iso do you Guix community recommend to install GuixSD ? The official 1.3.0 iso ? ***rekado_ is now known as rekado
<the_tubular>cocomeat4[m] yes, although 1.3.0 is a bit old, you might face some problem when you guix pull <luke-jr>the_tubular: currently, it does not work at all without substitutes <luke-jr>actually, the 1.3.0 install itself also doesn't work without substitutes :/ <blake2b>hiya guix, I want to build a system image that includes a home configuration, but can't seem to find any info on how to do this. any pointers? <rekado>luke-jr: because package source code moves and disappears from the web? One of the purposes of the substitute servers is also to cache source code, so you can get it from there. <littlebobeep>rekado: substitute servers have source, not just substitutes? <zamfofex>littlebobeep: Sources can also be subsituted, from what I understand! Anything that can be on the store can be substituted, I think. <littlebobeep>zamfofex: okay that is in the store, but I am asking about the pulic substitute servers, I thought they just had binaries (not sure I never used them...) <zamfofex>littlebobeep: Try, e.g. ‘guix build --source liquidwar6’ <rekado>the noun “substitute” describes anything that can stand in for a local build of a derivation, even if that derivation only results in source code. <sneek>civodul, you have 1 message! <sneek>civodul, unmatched-paren says: I've sent a massively improved version of the qbe patch to the mailing list: https://issues.guix.gnu.org/53833#10 and cproc, although at the time of writing the cproc package hasn't appeared on the mailing list. <efraim>civodul: I'm testing the update to mrustc locally, I'd like that in staging <efraim>looks like some of the aarch64 build failures are repeats of the TLS errors <civodul>efraim: hey! re mrustc, alright, feel free to push if/when it passes your tests <civodul>jpoiret: nice patch! doesn't it break a test or two though? <civodul>i think transformation properties get lost <jpoiret>when i checked they didn't though but i might be wrong <civodul>that would be in tests/packages.scm, i think <jpoiret>also, guix shell profiles don't have provenance info <civodul>mothacehe: ah weird, we had something similar for the "master" jobset the other day <mothacehe>we should maybe define some timeout for evaluations, so that the never finishing one do not consume all the db slots <civodul>"make cuirass-jobs" does work for me, so i'm not sure what's going on <civodul>the other day i attached gdb to those processes on berlin, and they had like 120 threads, all stuck on a mutex or something <civodul>i couldn't figure out what they were waiting for <sneek>ngz was in #guix one month and 15 days ago, saying: The ".postN" suffix is not unseen in this project. They released a 7.0.0.post3 some time ago.. <civodul>efraim: BTW thanks for reviewing & applying patches! <jpoiret>civodul: for the additional test, should it belong to guix-package.sh? by the way, those two scm tests you mentioned really aren't related to the changes, they directly test manifest transactions, whereas the patch's changes only apply to the `guix package` script <kete>thanks, cmack, I'm taking a look at that teddit thread. <blake2b`>hiya guix, is there a way to add a home-environment to a system profile? something like, perhaps (simple-service 'system-home home-service-type (local-file my-home.scm))? <blake2b`>sorry, I meant a system configuration, not profile** <civodul>jpoiret: rather a unit test, prolly tests/packages.scm or tests/transformations.scm <karrq>hello, I'm having issues upgrading my guix install, there's some kind of error with no code for module gnutls... can anybody help me upgrade? I can't even install some packages since it looks for substitutes and it fails there <jpoiret>civodul: but it should call the `guix package` command directly, right? <blake2b`>if someone points me in the right direction, I promise to document it for future users! <karrq>well I guess I can pull with --no-substitutes... <jpoiret>karrq: on which command does the error appear, and at which point? <jpoiret>blake2b`: there isn't a way to do that yet from what i gather <blake2b`>damn. perhaps after I'm done with the gig I'm currently working on at the end of the month I'll finnagle it together <blake2b`>would be nice to be able to build a bootable USB of my desktop <karrq>jpoiret: I'm trying to reproduce it now as I got a different error with guix pull --no-substitutes. actually I got a bug and it says to report it :P <jpoiret>can you paste it at paste.debian.net? <karrq>yes, it seems even without --no-substitutes it failed <civodul>jpoiret: hmm actually yes, you may be right; so in that case, guix-package.sh may be more appropriate <jpoiret>right. I'll write some dummy packages that reproduce the error (in between yesterday and today, emacs-consult was updated and no longer compiles at all, as well as having renamed their branch to main... :p) <karrq>I didn't pull for a while and last time I tried to pull (last week) I got a differnent error than this <jpoiret>did you properly source the guix pull profile in your shell? (ie `. ~/.config/guix/current/etc/profile`) <civodul>jpoiret: in general it's a tradeoff: the test has to be sufficiently focused, not too complicated, and robust enough so that it won't break next time someone changes some random package <jpoiret>by the way, can --with-patch= be properly replayed? <jpoiret>i'll try looking into it (and use that for the tests, as the other transformers would be harder to use with dummy packages) <karrq>jpoiret: I'm using fish and I did make a custom script to source, and checking the contents of the profile and the current $PATH it looks ok <karrq>(ie, the path is present and the hash is the same) <jpoiret>right, but your guix is trying to use your foreign distro's gnutls <jpoiret>do you know what is the fish equivalent of `command -v`? to check which executable is being called <jpoiret>the default guix wrapper should set %load-path with all libraries in front including gnutls <karrq>jpoiret: which guix ? /gnu/store/...-profile/bin/guix <karrq>I didn' thave these issues before tho <jpoiret>it looks like a bug on guix's part here <jpoiret>karrq: can you paste /gnu/store/iaiwgwyqarx13y47yd8krn6zyrxzqfqs-compute-guix-derivation please? <jpoiret>i'll just finish writing a test for a previous commit and have a look, but it seems that we don't bootstrap gnutls properly when building the new guix derivation <jpoiret>so it ends up loading whatever's available, here your distro's gnutls which doesn't work since it seems to be guile 2 <karrq>I'm on Arch, gnutls-cli is v3.7.4 <ulfvonbelow>I'm trying to package some python packages, but the requirements in 'check_requirements.txt' are never found, even though they're importable and usable <jpoiret>are you using the importer? did you run it recursively with -r? <jpoiret>otherwise the importer doesn't try to import dependencies if they don't exist <jpoiret>karrq: alright, i think i've found it <ulfvonbelow>it says "ERROR: Could not find a version that satisfies the requirement importlib-metadata>=3.6.0 (from versions: none)" <ulfvonbelow>I know that the version we have isn't that high, but it specifically says "from versions: none" <ulfvonbelow>and I've run into the same error with other packages where the version is high enough <jpoiret>looks like the requirements.txt aren't as simple <jpoiret>i don't think the importer knows how to deal with this, you'll have to add the dependencies manually i think <ulfvonbelow>I did, that package definition specifically includes python-importlib-metadata, and the 'check' phase specifically says 'versions: none' <civodul>we have a problem! rust-instant 0.1.9 fails to build <civodul>-> failed to select a version for the requirement `wasm-bindgen-test = "^0.3"` <jpoiret>ulfvonbelow: looks like we have 1.5 packaged, so not >=3.6.0 <jpoiret>karrq: can you paste the output of /usr/bin/guix describe? <ulfvonbelow>it subsequently says: error: Command '['/gnu/store/j3cx0yaqdpw0mxizp5bayx93pya44dhn-python-wrapper-3.9.9/bin/python', '-m', 'pip', '--disable-pip-version-check', 'wheel', '--no-deps', '-w', '/tmp/guix-build-python-httplib2-0.20.4.drv-0/tmphnbvo0lx', '--quiet', 'six>=1.10.0']' returned non-zero exit status 1. <jpoiret>looks like the testwith your second paste, i get an error about pytest instead <jpoiret>maybe you should relax the pytest requirement as well? <ulfvonbelow>huh, I thought I had tried that, but I guess I hadn't <ulfvonbelow>apparently I didn't bother uncommenting the requirement-relaxing portion after adding the python-six input <jpoiret>karrq: as a follow-up to that, can you try running `guile`, and inside the repl `(use-modules (gnutls))` <ulfvonbelow>so I guess 'from versions: X' doesn't mean "all known versions are X", but rather "all known versions /satisfying the requirement/ are X" <karrq>I have to say that the guix you ask of me is not from guix pull... <jpoiret>so this is the issue, the arch-installed guix does not work :) <jpoiret>because gnutls's guile bindings don't for some reason <karrq>but it definitely used to work, I installed a couple of packages a few months ago via guix <karrq>how can I fix this then ? :( <karrq>I used the guix-install script in the past <jpoiret>but there were some recent updates to the gnutls package in arch apparently <karrq>if I try to run the script now it refuses to install as guix is present already <jpoiret>hang on, are you using the arch-packaged guix or did you install it yourself? <jpoiret>see the topmost comment there, this should be the root of the issue <jpoiret>maybe it's arch trying to tell you to switch to guix system instead :p <karrq>hmm hang on... this is weird. I remember removing the stripping for the AUR package... or not... still, it sucks that I can't guix pull... I was always assuming guix pull always worked, basically... <karrq>how can I fix this tho? Is there a way to go around this? Perhaps build from source with guix-provided gnutls? <jpoiret>you could try using the guix-daemon from ~/.config/guix/current/bin/ instead <jpoiret>that'd require shutting down your guix daemon through systemd (i assume), and starting that one instead using the same flags <karrq>well I can do that... --build-users-group=guixbuild is the only argument passed <karrq>but I'm not familiar enough to know how to proceed from there <jpoiret>once the new guix daemon is running (as root), you should be able to keep using guix and guix pull <attila_lendvai>another "In procedure write_wait_fd: unimplemented", several minutes into a make check-system run... :( <jpoiret>be careful though, you're using user-installed software as root (maybe i should've mentioned that earlier) <jpoiret>that means that anyone that can modify ~/.config/guix/current/ could get you to run arbitrary software as root <karrq>so I need to always run the deamon like this when I want to use guix? <karrq>that is, until the issue with gnutls is fixed? <jpoiret>you could also have a middleground, by `guix pull`-ing as root and using the root's guix <jpoiret>but yes, until that issue is fixed, the arch-provided guix won't be useful <ulfvonbelow>today I learned that the pypi importer can give circular dependencies, e.g. python-jaraco.context depends on python-pytest-enabler which depends on python-jaraco.context <ulfvonbelow>this presents a very perplexing situation in which the prerequisite to testing python-jaraco.context's functionality is that python-jaraco.context's functionality is working <nckx>Circular dependencies be circular. <nckx>Does 'the issue with gnutls' above refer to a known bug? <civodul>good question, what is "the GnuTLS issue"? i see jpoiret mentioned it earlier but i didn't follow <nckx>ulfvonbelow: The most guixy solution would, I'd say, be to (manually) create a hidden python-jaraco.context/untested variant with which to build the package proper. I agree it still feels odd, I guess because the small size of the circle. <jpoiret>but everyone that uses arch-packaged guix will run into it <nckx>How well is arch-packaged guix packaged? (I mean, are we talking AUR rando, or well-known Guix weirdo...?) <nckx>I consider us all weirdos, I wasn't singling out Vagrant. <civodul>jpoiret: looks Arch-specific, good :-) <ulfvonbelow>how does one build, test, and install a python package that has no setup.py, just setup.cfg? <rekado>ulfvonbelow: maybe with python-pypa-build. Running somethink like (invoke "python3" "-m" "build" "--wheel" "--no-isolation" ".") in the build phase. <ulfvonbelow>hmm, that gets me a fair bit farther, though it fails later on with "ValueError: ZIP does not support timestamps before 1980" <rekado>maybe (setenv "SOURCE_DATE_EPOCH" "315532800") <ulfvonbelow>nice, and is there a corresponding target for installing? "-m" "install" or something like that? <ulfvonbelow>I tried (invoke "python3" "-m" "build" "--outdir" #$output) and now it says it wants a newer version of setuptools. 'guix import pypi -r setuptools' outputs around 130 package definitions, most of which are something to do with objective c for some reason, and naturally the first package it outputs (python-build) has a circular dependency with the last package it outputs (python-setuptools) <ulfvonbelow>I'm not sure whether the pythonistas are insane or I am <apteryx>rekado: hello! I've had 2 old drives failing at home, so I took it as an opportunity to resplenish my setup with new SSDs. I'll have 5 total to put into a Btrfs RAID10 array soon, it'll be interesting to see if I encounter problems like we do on berlin. <apteryx>ulfvonbelow: there are a few examples already for pep 587 style builds <ulfvonbelow>apteryx: thanks, that's about what I needed. However the "check" phase isn't working for me - it keeps giving "collecting ... ERROR: file or directory not found: tests/unit/". The README says to use tox, so I tried that, and it complained about /homeless-shelter/.cache/pip not being writable... <ulfvonbelow>apparently one of the packages built with guix's current python-build-system is getting its version recorded as 0.0.0 <apteryx>you probably want to override whatever setuptools invokes by default, as it most often doesn't work, especially with pytest <apteryx>so copy paste a check phase override doing (when tests? (invoke "pytest" "-vv" "tests")) or similar <apteryx>also the tests are often not shipped in pypi sdists, you may need to checkout from git <ulfvonbelow>I tried checking out from git using git-fetch, but now it gives "LookupError: setuptools-scm was unable to detect version for '/tmp/guix-build-python-path-16.4.0.drv-0/source'." It says it wants a "fully-intact" git repository. <ulfvonbelow>Is there a way to specify that with the git-reference? <jackhill>Does anyone with commit rights have time to look at #55078? It's a minor webkitgtk upgrade. I just did a build and smoke test, and it LGTM! <doncatnip>i wonder if it was possible to leverage tech like torrent, blockchain, ipfs to have some sort of decentralized CI and archive <bjc>if by “blockchain” you mean “git”, then i don't see why not <doncatnip>i mean the idea behind blockchain .. use that principle for a distributed state .. well yeah i guess sortof like git, but autonomously distributed with a decentralized mechanism for validation and integrity ... i think there is great potential for something truly amazing when combining web3 and deterministic, reproducible declarative builds <bjc>git verifies its own integrity. validation is a social problem <bjc>but you don't need etherium for any of this, for instance <bjc>git *is* a blockchain, it just doesn't have a consensus algorithm <doncatnip>its not really ... i guess you can have your definition fit it that if you really want to. i'm thinking autonomity and self organization .. git is pretty top-down (not a bad thing) and its infrastructure has to be set up manually .. git could be *used* within a decentralized CI still <cocomeat4[m]><the_tubular> "cocomeat4 yes, although 1.3.0 is..." <- what should I use then ? <doncatnip>if my computer has finished a build .. and a bunch of others have too .. there ought to be a way to create a swarm out of that and distribute it basically peer2peer <bjc>yeah, i think you'd be able to set up a torrent tracker for it <bjc>the biggest issue is that not everything is reproducible right now, so there's always going to be conflicts even in legitimate builds <unmatched-paren>bjc, doncatnip: pretty sure there were vague plans to use the gnunet for something like this in the future, might be wrong? <doncatnip>oh man using gnunet for all that would be pure nerd-porn <attila_lendvai>ERIS is an abstraction layer for content addressable immutable storage implementations <unmatched-paren>doncatnip: you could argue that the same is true of using scheme for a package manager :) <doncatnip>but the reason im thinking blockchain is is at least chains like cosmo have a solid solution for integrity with their byzantine fault tolerance and matching incentives <attila_lendvai>IOW, ERIS can be used as a front-end API that abstracts away IPFS, Swarm, gnunet, https, pendrives, etc <bjc>that's pretty cool, although if you farm out ci to the internet at random, i'm not sure how you establish trust at the level it currently is with a gnu-hosted solution <bjc>you and attila_lendvai <attila_lendvai>doncatnip, blockchains will always be expensive for such things. and what they add is a consensus mechanism, which in the case of Guix is its git repo and signed commits... IOW, a blockchain is a much less urgent issue for Guix than adding distributed storage. <bjc>i'm not sure there is a suitable consensus algorithm for something like guix; there will never be very many builders, so the ability to compromise some part of the substitutes seems ever-present <bjc>in some ways the guix system lends itself to it, since everything is content addressable <attila_lendvai>if you want to trust unknown builders to produce the substitutes, especially without having the keys in the guix maintainers for signing what to trust... now, that's a whole new level of stuff/complexity. <bjc>the problem is the gap between the merkle tree of the source and the build artifact. how do you *prove* this artifact came from this source? <doncatnip>attila_lendvai, maybe .. But maybe its worth the cost ... It's just a sponanious thought given the state the world is in right now. Think about the implications of having a serverless GNU distribution, not relying on any of the coperate controlled infrastructure, but on the people instead. guix as DAO basically, with all its data and communications. <attila_lendvai>bjc, reproducibile builds, random checks, and a web of trust can get you a long way. but it wouldn't give you all that much in return. while merely distributed storage already trusted content has a much better return on investment <unmatched-paren>'Some people, when confronted with a problem, think "I know, I'll use blockchain." Now they have int main(void) { problems." <bjc>attila_lendvai: yeah, i think distributed, signed storage makes a lot of sense. be it ipfs, torrents, or whatever <attila_lendvai>doncatnip, i'm in no way against that vision... :) i'm just pointing out that there are much lower hanging fruits that are still unpicked. <doncatnip>attila_lendvai: maybe guix is not the right adress for that .. but i think reproducible builds are *unmatched-paren needs to remember to CHECK that they have what they think they have in their clipboard before pasting <ulfvonbelow>regarding untrusted substitutes, the best I could see would be a sort of "compilation receipts" - for each choice a compiler can make, it defines a set of legal options, and as it makes the choices (potentially rather expensive choices), it records the outcomes explicitly. This record can then be sent to other compilers who then also make the same legal choices much more quickly. <ulfvonbelow>this is only really useful in cases where it takes far longer to make a quality choice than to verify that a choice is valid <bjc>ulfvonbelow: but when two builds conflict, how do you say which one is correct, or that any of them are? <ulfvonbelow>any builds that are the result of legal compilation receipts are valid, though some may be more or less optimal than others. That's the theory, anyway. <bjc>how do you link a build with a compilation receipt in a way that establishes it all the way back to a collection of source files? <ulfvonbelow>you would take the source files and compilation receipt, feed them both to your compiler, and see if the output it generates matches the build in question. <ulfvonbelow>the idea being that the slow parts of compilation involve educated-guess-and-check, and it's far faster to check once than to keep guessing <apteryx>oh, if I luksFormat a drive with our cryptsetup, does it use the now-incompatible (with GRUB) new encryption type? <apteryx>I hope I do not need to reformat the drives... <pmarreck>so I'm trying to install Guix on bare metal on a System76 machine and some important driver (probably nonfree) is missing from the linux libre kernel and it actually causes it to freeze during booting. Is there any way I can run something to determine which of my (apparently important) bus devices might be missing a free driver? <pmarreck>it would be great if the guix installer somehow vetted the hardware it was running on for this before going forward and tripping <pmarreck>it's a desktop in this case, I have a (sigh) 2080ti and a 3080ti currently slotted. (yes, I know...) *unmatched-paren does not know hardware :P <pmarreck>i thought there was a free nvidia driver though, nouveau? <unmatched-paren>well, it's either the graphics or the wifi, and the wifi is unlikely <apteryx>seems 'cryptsetup luksDump' no longer show the key derivation function <apteryx>jpoiret: did you have patches for grub for argon2? <pmarreck>unmatched-paren: based on the screen corruption at the bottom, it does look like a graphics driver issue <unmatched-paren>pmarreck: i'm not experienced with this kind of problem, so someone else will have to help you, sorry :/ <unmatched-paren>annoyingly, the corruption seems to hide the last part of the log >:( <unmatched-paren>it's possible it's just more "Non-free firmware is missing" i guess... <pmarreck>hey man it's cool! i'm just spending a little hackaround time investigating non-dumb software deployment tools, and nix and guix showed up often, and so far guix seems more appealing <unmatched-paren>pmarreck: as a last resort, you might have success with The Channel That We Do Not Speak Of <pmarreck>you even mentioning of its existence is surprising. say no more of it <unmatched-paren>obviously you should try to make nouveau work first ;) though I will be impressed if you get guix system working flawlessly on an AMD desktop with NVIDIA graphics with zero nonfree software <pmarreck>Right. The fallback might be a completely stripped down Ubuntu (to pick up the ZFS support along the way :: cough:: CDDL does not conflict with GPL unless you ship binaries together :: cough ::) and slap Guix on that to manage basically everything going forward. <unmatched-paren>Guix on a foreign distro is way less powerful than guix system, i must warn you <unmatched-paren>You lose /etc/config.scm, rollbacks from the boot screen, and shepherd <bjc>pmarreck: there are plenty of issues with zfs and guix (ask me how i know!), but the license isn't one of them <bjc>literally any out-of-tree filesystem would have the same problem, regardless of license <doncatnip>attila_lendvai: re ERIS - glad to see people much more productive than me already thought about the exact same thing :) <unmatched-paren>although guix-on-foreign is still way better than traditional package managers <unmatched-paren>pmarreck: Foreign Guix is sometimes a bit more annoying to set up (running it on Debian was painful) <attila_lendvai>apteryx, cryptsetup can convert from LUKS2 headers to LUKS1 inplace <jpoiret>apteryx: what, why would they remove that <jpoiret>and no, only have patches for grub-install to support basic LUKS2, but there are patches for Argon2i on the MLs <jpoiret>i haven't seen any activity related to my patches (or any other LUKS2 patches for that matter) in a bit <jpoiret>hmmm, actually there is, with yet another patch set that does things, well, arguably worse than mine... but that is getting reviewed this time <vagrantc>huh... build of /gnu/store/jq03j5g61vhfg64hl4wrnl63skdj8da1-openjdk-12.33.drv failed ... error: in phase 'fix-java-shebangs': uncaught exception: <vagrantc>system-error "mkstemp" "~A" ("No such file or directory") (2) <jpoiret>it was transient though, maybe a full /tmp? <apteryx>jpoiret: eh, perhaps you should tip in as a reviewer, yours may have fallen into the cracks <jpoiret>i'll try replying to one of the reviews, mentioning the relevant part of my patch. maybe we'll be able to combine them :) <apteryx>arg. GRUB still freezes after 'Slot 1 opened' <apteryx>(after entering the LUKS passphrase of my 1st disk) I wonder what could be causing that <apteryx>I thought it was the pbkdf2 key derivation, but I've 'cryptsetup luksChangeKey --pbkdf=pbkdf2' them all now... <luke-jr>rekado: can I accept substitutes for source files only? <apteryx>very weird, it worked better at 'cryptomount -a' in the grub rescue, I could boot now <jpoiret>luke-jr: there's no way to tell if something's source or not afaik <jpoiret>oh, maybe fixed-output derivations only <jpoiret>but i don't think there's such an option right now <luke-jr>jpoiret: so it doesn't really work as a source mirror <jpoiret>just that there isn't a `--substitute-only-fixed-output-derivations` option <luke-jr>sure, but the problem is a user who wants to build everything from source, can't really right now <luke-jr>latest was broken until a few hours ago :P <jpoiret>arf, maybe swh fallback could help, but I don't know how it works <apteryx>when I invoke cryptomount -a at the grub rescue, it starts at (hd0, gpt2), while GRUB itself starts at (hd1, gpt2) for some reason <apteryx>phew. main machine back up, after 2 out of 3 drive failures on the RAID1. <apteryx>vagrantc: I bought 2 new ones and replaced the ones causing failures <apteryx>but I was rusty with btrfs and hit all the gotcha, it seems. The road was long. <apteryx>note to self: leave the system up and running if possible until getting the replacement drive, then use 'btrfs device replace' while the old drives are still connected; finally reconfigure the OS otherwise GRUB won't know about the new drives <apteryx>I'm still getting a very odd hang at boot after the 2nd drive (hd1, gpt2) is unlocked (LUKS-encrypted), as I've mentioned earlier. Not sure what that may be caused by, perhaps it doesn't like the new SSDs. <apteryx>I can work around it by entering a broken passphrase -> grub rescue -> cryptomount -a -> insmod normal -> normal <jpoiret>luke-jr: well, swh fallback should theoretically come in whenever a source's not available, but i haven't run into it (i use substitutes myself) <nckx>luke-jr: To get around a known-broken source, you could try 'guix build --source --substitute-urls='...'', where said URLs are properly authorised. It's possible (but unlikely) that Guix could substitute prerequisites for the source, like, hm, hg? but it's unlikely. Add --dry-run to check. It's certainly not optimised for convenience. SWH etc. fallbacks should just become more robust. <nckx>*guix build PKG[s] to be specific.