IRC channel logs
2024-02-03.log
back to list of logs
<podiki>not sure on the details, but i think that is the idea. if you look at something like udev, it will combine all extensions to have a rule list <podiki>on the note of oci-container-service-type, I have a local modification to create docker networks with it, so containers can be on the same (internal) network to talk to each other, like docker-compose does by default <podiki>unrelated, figured out how to use ping from a container: set net.ipv4.ping_group_range to allow users (or a user) to ping, so doesn't require setuid <takev>That modification sounds really useful! Do you happen to have it somewhere I can look? <vagrantc>can anyone find a meaningful build log of wabt on ci.guix.gnu.org ? all the ones i can find are either missing or contain virtually no information <vagrantc>how do you generate the source hash when something uses git submodules? <vagrantc>other than just building it with the wrong hash and then copying the one it got ... <podiki>you could manually do a clone (recursive), checkout, and then guix hash -rx ? <podiki>takev: oci-container-net-shepherd-service i think is the only modification you need really, the whole start gexp part is what does it <podiki>takev: still need to decide the right interface and defaults for this, but wanted to get some version working first. i'll submit a patch or maybe get feedback on guix-devel soon <ulfvonbelow>does 'guix graph --path' not work with cyclic graphs? <ulfvonbelow>would be a shame, given it's otherwise basically the perfect tool for identifying the members of a cycle <vagrantc>podiki: so far i did git clone ... git submodule update --init ... but that is clearly not working <vagrantc>podiki: what worked was git clone --recursive X && guix hash -rx X <vagrantc>so i guess i just do not know how to replicate "git clone --recursive" behavior after just initially doing a "git clone" <ulfvonbelow>git submodule init maybe? (I've never tried it either) <vagrantc>as in, i just confirmed that that does not end up with the right hash. <ulfvonbelow>the right hash compared to what 'git clone --recursive' gives or compared to what (git-reference ... (recursive? #t) ...) gives? <ulfvonbelow>hmm, looks like (guix build git) does (invoke git-command "submodule" "update" "--init" "--recursive") <vagrantc>is there a verbosity setting where i could actually see that in the build logs or something? <ulfvonbelow>I don't think so, you could probably see the output of that command by default if it produces any, but the invocation itself will only show up if invoke raises a &invoke-error because the command failed <vagrantc>ok, and now the reason i've been poking at this ... wabt has been failing to build on architectures other than x86_64 ever since tests were enabled ... it has a history of test suite failures on non-x86 architectures ... other distros seem to just disable tests <vagrantc>9d474e105977e46d1ffd9afe794d26882a66c7a0 gnu: wabt: Update to 1.0.32. ... is where they were enabled <vagrantc>which means no diffoscope on anything other than x86 <vagrantc>i am tempted to propose just disabling tests on architectures other than x86_64 ... <vagrantc>now let's see if i can figure out how to do that ... i know i've done it somewhere before :) <vagrantc>never really wrapped my head around conditionals in guile <ulfvonbelow>do we have any rusts with documentation? I'd like to be able to do some reading offline <vagrantc>ulfvonbelow: that sure looks simpler than what i was working on :) <vagrantc>doesn't even trigger a rebuild on x86_64 <takev>podiki: This is wonderful, thank you! <apteryx>jpoiret: this looks useful in debugging the cycle: ,trace (with-store store (run-with-store store (lower-object pkg-config)) <podiki>takev: welcome! was hoping to find something cleaner but so far only got that version to work (bit hacky to me). i will test moving my docker-compose to that and then look to upstream it <snihil>hey Guix! I was reckless enough to attempt something and it broke my system. I would need a rescue boot usb stick to fix it. Anyone here at FOSDEM? <nmeum>I have a patch for a new Guix package that I would like to send upstream. The package requires several new OCaml dependencies; should I add each one of those dependencies in a separate commit, or is it fine to add the package and all of its dependencies in one commit? <wigust>nmeum: usually commiters do a separate commit per package <PotentialUser-31>Hello. The download page says guix system can be installed on aarch64 but there's no image to download. <davidh38>does anyone know, why terraform is not in the guix packages? <davidh38>is it not open source or is it just hard to compile? <ieure>davidh38, It's not there because nobody has taken the time to package it. <davidh38>ieure hmm, do you think, that there would be a need for it? <sham1>Also its license seemsā¦ not exactly free <zamfofex>PotentialUser-31: It shouldnāt be difficult to crossābuild it from x86(ā64), though. <ieure>sham1, Hashicorp relicensed it in 2023 and pissed everyone off, the community forked OpenTF and is leaving Hashicorp's shit behind. <ieure>davidh38, Presumably you have a need for it, otherwise you wouldn't be asking. <sham1>Also I just don't know what use Terraform/OpenTF would have since we already have a very powerful way to define infrastructure stuff in a way that be reproduced <ieure>sham1, Yes, agreed. But I suspect very few shops are using Guix like that, and being able to manage existing fleets from your Guix is nice. <ieure>davidh38, One of the things I appreciate about Guix is that it's easy to make your own packages that exist on equal footing with the bundled ones. So you can readily make personal packages that don't belong in Guix proper. You also don't have to wait on review and approval to use what you need immediately. <ieure>You *can* do this with other distros, but it's much harder. Guix makes it very easy. <sham1>Fair enough. I would feel that we should try to push that, maybe even alongside the Nix people, since this kind of a usage would be a great application for both projects <ieure>I have packages for some really niche software that I think almost nobody else would get value from. I keep them in my own channel, and don't sweat that they're not "in Guix." <davidh38>ieure makes sense, let me just compile terraform from the source, then I might come back to you. <ieure>singpolyma, Eh. I really dislike when I write a thing for me and then someone with zero context on any of it wants me to change stuff. This is why I don't bother submitting anything to ELPA anymore. <PotentialUser-31>zamfofex so if I understand correctly i'd need to use a x64 guix to build a guix arm image? <davidh38>oO I compiled terraform, but I have no idea, how to build the package now. Is the guix documentation showing this, how to do this properly? <davidh38>Can anyone explain to me, why go is part of guix and I dont need gcc to compile go? I would have thought, that I should build go from the source. Where is my thinking wrong? <sevan>davidh38: because go is now self hosting right? (go can compile itself) <sevan>davidh38: gcc have a go support, that is you can use it instead of the go utility to compile your code but it doesn't support all targets that the go utility does e.g macos <davidh38>sevan but if you compile go with go, you need to start with binaries and these are written in C or C++Ā or am I wrong? <zamfofex>PotentialUser-31: Yes if you canāt find Guix (either the distro or the tool) prebuilt for ARM. But once you have a Guix built for ARM (either distro or tool), you can use it to build a system image natively. <sevan>davidh38: there is a bootstrapping version of go which is the last version written in C, is that what you're lookin at? (I'm not doing golang on guix) <apteryx>does using gexp in a package means the derivation has extra dependencies like guile? <ieure>Doesn't every package implicitly depend on Guile, since the build steps are Guile programs whether they use gexps or not? <apteryx>yes, but perhaps a different variant? <apteryx>ACTION is (still) trying to understand how a cycle comes into life. <apteryx>actually just attempting to produce the derivation with ,lower causes the hang <ulfvonbelow>build systems produce a derivation usually using (default-guile), however in pretty much all of them this can be overridden by an explicit #:guile argument <klm`>Hi! I want an avr-gcc based on gcc-13, how do I do that? I tried this: `guix build -e '(begin (import (gnu packages cross-base) (gnu packages gcc)) (cross-gcc-toolchain "avr" #:base-gcc gcc-13)))'`, but it fails: 'The directory that should contain system headers does not exist: ā¦'. <sevan>klm`: does gcc 13 actually support an AVR target? <sevan>klm`: in a completely unrelated conversation, I heard from someone that the toolchain was stuck on GCC 8 <klm`>Yes, I've used it before. <klm`>I've heard such roumors myself, but they can't be right: the latest avr-libc on github.com/avrdudes/avr-libc needs gcc-13 to support its newest AVR targets <klm`>I had an old and messy guix package spec that used to work with that github avr-libc and gcc-13. but now, since this cross-gcc-* feature, my package no longer works. <klm`>Am I using (cross-gcc-toolchain ā¦) right at least? <sevan>if you want to roll your own ^ <klm`>hmm ... hang on, it seems the package gcc-cross-avr-toolchain doesn't work properly. its `avr-gcc -target-help` lists attiny1614, but it fails if I specify `ā¦ -mmcu=attiny1614`. "warning: device type not defined", it says. There may be a problem with this package definition. <klm`>sevan: btw, avr-libc has moved to github.com/avrdudes/avr-libc <klm`>How can I for `guix build ā¦` to rebuild? I'd like to look at the build logs. <ieure>klm`, `guix build --check ...' <ieure>And you can find that with `guix build --help | grep -i rebuild' <klm`>I tried that, but it's not giving any more output. <klm`>guix build --check gcc-cross-avr-toolchain # gives me 4 lines, all "successfully built ā¦". <ieure>Not sure then, maybe `--log-file'? <klm`>adding `--log-file` seems to put the "grafting ā¦ -> ā¦" log into a file instead of my terminal. <klm`>ulfvonbelow: thanks, that helped, that yields more output. but it's still not recompiling anything, or re-running ./configure which is what I'm after. <klm`>I guess gcc-cross-avr-toolchain is special in that it's basically just a composition of other packages, like a special cross-gcc and cross-libc. <ulfvonbelow>if you try accessing it from tor like me, it's always down <ulfvonbelow>you can s/issues.guix/debbugs/ and see the same issue <davidh38>dave@host /usr/local/aws-cli/v2/current/dist$ aws <davidh38>dave@host /usr/local/aws-cli/v2/current/dist$ sudo aws <davidh38>dave@host /usr/local/aws-cli/v2/current/dist$ source aws <davidh38>bash: source: aws: cannot execute binary file <davidh38>dave@host /usr/local/aws-cli/v2/current/dist$ <davidh38>does anybody have an idea, why I can not execute the binary? <ulfvonbelow>klm`: indeed, the *-toolchains are all just symlink unions of various packages like binutils, gcc, and libc <ulfvonbelow>specifically, cross-gcc-tolchains are produced at line 733 of (gnu packages cross-base) <klm`>ulfvonbelow: right, makes sense. Is there a way to reference the libc that gcc-cross-avr-toolchain is using so I can run `guix build --check ā¦` directly on it? <ulfvonbelow>we see there that xbinutils is produced by calling (cross-binutils target), and libc is produced by calling cross-libc, and xgcc is produced by calling cross-gcc <klm`>I'v poked around at that, but I find it difficult to reproduce the exact libc package that's being used by gcc-cross-avr-toolchain. <klm`>Ah, I think I get it. The log in https://paste.debian.net/1306217/ is showing all the things that are being symlinked into the gcc-cross-avr-toolchain build. And I'm looking for the avr-libc package it's using. <ulfvonbelow>guix build -e '(begin (set-current-module (resolve-module (quote (gnu packages cross-base)))) (let* ((target "avr") (base-gcc %xgcc) (xbinutils (cross-binutils target)) (libc (cross-libc target #:xgcc (cross-gcc target #:xgcc base-gcc) #:xbinutils xbinutils))) libc))' <ulfvonbelow>that should pretty accurately reproduce what it's doing <ulfvonbelow>if not, note that you can also dive into the derivation produced for gcc-cross-avr-toolchain and find the derivation corresponding to libc yourself <ulfvonbelow>hmm, now that I try running that expression I see it gets an error, give me a sec <podiki>davidh38: if you look at the contents of awscli, the commands it provides are awscliv2 and awsv2 <klm`>ulfvonbelow: When I run it, I get: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #<syntax-transformer %xgcc> <podiki>davidh38: if those should be named differently or some other issue, you might want to check the package definition first to see what was done and why. e.g. guix edit awscli <klm`>davidh38: there is a packages awscli for Guix in case you're not using that already: guix show awscli <ulfvonbelow>okay, try this instead: guix build -e '(eval (quote (let* ((target "avr") (base-gcc %xgcc) (xbinutils (cross-binutils target)) (libc (cross-libc target #:xgcc (cross-gcc target #:xgcc base-gcc) #:xbinutils xbinutils))) libc)) (resolve-module (quote (gnu packages cross-base))))' <klm`>wow cool! with --check and --no-grafts it's finally running that avr-libc configure script <klm`>is the eval to import the %xgcc syntax? which in turn is used to delay evaluation of `gcc` to avoid recursive dependencies? <ulfvonbelow>yeah. The (set-current-module) before was supposed to get it, but apparently it confused guile a bit <ulfvonbelow>I guess it tried to macroexpand the entire form first, in an environment where %xgcc wasn't bound, then it evaluated set-current-module, then it evaluated %xgcc without trying to macroexpand it <klm`>I don't get that whole business. Why is a reference to gcc itself problematical? And how do I now get gcc-13 in there instead? <klm`>also, the comment for %xgcc (cross-base.scm:58) says "don't reference gcc from top level", which we wouldn't be doing if we just do guix build -e '(let ā¦)', right? <ulfvonbelow>ah, yes, I suppose in the expression passed to 'guix build' itself it would be fine to use gcc instead of %xgcc, I just wanted to be as faithful as possible to what cross-gcc-toolchain does <klm`>so you basically copied the keyword parameter initialization from cross-gcc-toolchain/implementation so that we could get just its libc reference? <ulfvonbelow>it may have ended up being more straightforward to 'guix build --derivations gcc-cross-avr-toolchain' and then find the derivation for the cross libc <klm`>ulfvonbelow: indeed, that is an excellent tip: guix build --no-grafts --derivations gcc-cross-avr-toolchain # has, amongst other things, /gnu/store/izpszw8zr34k6ph23lmy3cb2dh5mqzss-avr-libc-2.0.0.drv inside it. running `guix build --no-grafts ...` on that in turn let's me rebuild avr-libc. thanks a lot for helping out with this.