IRC channel logs
2025-04-03.log
back to list of logs
<theruran>but there are no ARMv7 or AArch64 Guix System images <meaty>theruran: you may have to generate one yourself then, Guix has tooling for this <meaty>theruran: `guix system image`, look it up in the manual. It lets you construct a livecd from an operating-system declaration <meaty>and iiuc it will cross-compile to the right arch <ieure>theruran, ARM platforms are wildly divergent, meaning it's not possible to create a single install image like it is for PC hardware, and it's impractical to maintain N hardware-specific images. <ieure>So you have to roll your own. <RavenJoad>I have tested all of Souffle's functionality (interpret, compile, Swig, and SQLite) and they all work. Please email the thread if I missed something important! <apteryx>anyone ever used make-systemd-constructor with a least-authority-wrapper wrapped program? <apteryx>I guess I need to leak LISTEN_PID, LISTEN_FDS and LISTEN_FDNAMES environment variable for it to work? <apteryx>I'll test, but if confirmed, we should probably add these to %precious-variables in (guix least-authority) <theruran>thanks ieure. I'm on Apple Silicon M2 - I have Guix running on Asahi Linux, so it should be possible to generate a Guix System aarch64 image for VirtualBox, right? <meaty>Hello guix, I'm having some trouble packaging meteo-qt, a python/qt app. it appears that Guix thinks executables that I *know* are in the qttools package are actually in the qtbase package, and I don't know how to correct it <auk>Hello channel, i have a patch for guix-install.sh that i'd like to submit. Should i just send it to guix-patches@gnu.org, or is there anything else I should do or consider first? <apteryx>I wonder why a %simple-os operating system VM doesn't have any console output when used with -nographic <apteryx>(these are often used in system tests) <apteryx>meaty: Qt assumes heavily a global FHS installation <apteryx>we try to patch things in some places, perhaps more patching is needed <apteryx>auk: if you've tested it and it works fine, yes, please send it to guix-patches@gnu.org <meaty>apteryx: any pointers as to where to go for this one? <apteryx>maybe look at tE qtbase-find-tools-in-PATH.patch patch applied to qtabse <apteryx>perhaps it's missing stuff; perhaps also compare with upstream latest version (from NixOS) <apteryx>looks like it uses a new environment variable QTTOOLSPATH but we don't set this anywhere <apteryx>I'd review this and make sure it finds the tools on PATH (this may also be the case, on top of QTTOOLSPATH) <apteryx>an qttools placed under bin/ as usual for PATH? <auk>apteryx, ok, I'll review it again and send it in when ready. I've tested it ad-hoc/manually. There don't seem to be any automated tests (e.g. with bats or shellspec) for guix-install.sh, unless I missed them? <auk>apteryx, there are some implementation details in the patch which are probably worth discussing. I'm not sure if it's better to do that before or after emailing the patch? <apteryx>you can do so in a cover letter if you'd like <auk>apteryx, ok, thanks! i'll do that <kuromedayo>I don't have much experience, so this may be a silly question: I'm trying to package some software that takes a long time to build, is there any way to speed it up by building it on a server instead of building it locally? Is this an underused method? <auk>kuromedayo, i might call using a build server an 'overused' method, at least by those who have access to build servers :) <auk>kuromedayo, i'm new to guix, but that looks like it is it, yes. I don't know how they manage access to it <auk>kuromedayo, it seems to only build from the official guix git, so i guess you'd need commit access to make use of it <auk>kuromedayo, there are some free build/CI/CD servers provided by various corporations online. (Usually with limits, but it might be enough for you) You might be able to make some of those work for your project <auk>kuromedayo, i'm curious what software you're packaging? <apteryx>kuromedayo: 'offloading' is a relatively cheap (setup wise) way to have something built on a different machine, if you have one <apteryx>ci.guix.gnu.org is not open to the public, for security reasons, but you can also run your own instance of Cuirass (it's suprisingly easy) <kuromedayo>auk: I see, thank you! I also found this in the cookbook. I'll give it a try. <apteryx>for hands-on development though, I'd recommend working in the git tree without a 'guix shell' environment to avoid the waste of copying files and rebuilding from scratch every time, and speed up iterations <kuromedayo>apteryx: I did not know about those things. I'll look into that. Thank you for the great information <miha>hi! Has anyone set dns provider in resolv.conf? <miha>this has been my approach but it fails <miha> (network-manager-service-type <miha> config => (network-manager-configuration (dns "none") (vpn-plugins '(network-manager-openvpn)))) <miha> (static-networking-service-type <miha> config => (static-networking (inherit config) (name-servers '("9.9.9.9" "149.112.112.112" "2620:fe::fe" "2620:fe::9"))))) <PotentialUser-80>Hello guix. Is there a commandline switch to pipe all the store paths that are written to stdout when running guix build --sources=transitive package_name. Or can I even automagically pack the sources into in archive? <zilti>I am defining a package, but I have to generate a file the build script expects. It expects "build/version.info". I tried to use `plain-file`, but of course I have to create the subdirectory first, and also, `plain-file` seems to not be able to create files in subdirs. <identity>zilti: are you using git-fetch? the version.info file is probably included in the release tarballs <zilti>identity: no, unfortunately I have to work with a tarball, where it is not included <Tlmnz>When are you gonna fix your shitty scheme implementation retards <zilti>Tlmnz: wtf is wrong with you? <Rutherther>Plain file is completely unsuitable here, it makes a new store path. You would want something like mkdir-p and with output to file to create it in cwd of the build environment <Tlmnz>YOUR SCHEME IMPLEMENTATION HAS STUPID BUG AND YOU CANT FIX IT AND GUIX TOOK TO MUCH SPACE ON MY PC AND CANT USE IT <zilti>Rutherther: Ah. Ok. And is it better to do this as a "snippet" in the source section, or after the unpack phase? <jA_cOp>You got what you paid for, Tlmnz :) <Tlmnz>jA_cOp: Im not buying your hollywood stories <Tlmnz>Fucking american retards with their retarded language <Tlmnz>All you can do is running through empty fields on cows lol <csantosb>zilti: maybe `(invoke "touch" "build/version.info")` ? <csantosb>zilti: don't you have a .texi, .org file or something around to produce the .info file ? <jA_cOp>I wonder what they have against American languages? I bet they never encountered one <zilti>csantosb: No, I'd just use the package version to put in there. I guess I'll go with mkdir-p and with-output-to-file <csantosb>Hi Guix ! I'm looking for the right way to tag a contribution as a team issue <csantosb>I have failed with all my attempts, see #77275, any idea on how to do that properly ? <Tadhgmister>does anyone use `guix shell` and `tup` together? tup does some environment variable isolation and I'm having trouble figuring out how to get the dependencies working <Tadhgmister>right now I have tup runnign the command `guix shell -m manifest.scm -- python3 test.py` with a manifest that includes scipy and the test just imports scipy and that is failing inside tup but not when I just run it in terminal and I cannot for the life of me figure how that could even make sense <Tadhgmister>nvm it seems I hit some transient issue maybe with tup caching stuff incorrectly? idk i am good now <Tadhgmister>nope it seems to be non deterministic.... if anyone has experience using tup in guix I would appreciate some advice <divya>efraim: 1.86 is already here *sigh*. Did you answer my question about the bootstrap package? I don't think I got a ping <efraim>Divya, yeah, the checksum is for the new version <divya>Also efraim I saw a21bbfb712 in rust-team, did it finally fix the proc-macro-srv issue? <efraim> I'm not sure, I'll have to take a look. I'm currently working from my parents' place for the next month while we're traveling for the holiday <divya>No worries, I'll take a look and let you know if it works. <elevenkb>Hello there, when you use git-version do you have to increment the revision if the version is incremented? I'm inclined to say "no" because the versions are lexicographically sorted. <Rutherther>I would even go as far as setting it to zero after updating. But I am not sure on the official policy in the guix channel <elevenkb>Rutherther: Thank you, have to fixup a channel update then. <identity>elevenkb: (info "(Guix) Version Numbers") ;; section 22.8.3 <elevenkb>identity: thanks for showing me how to do info links, let me try them myself (info "(guix) Version Numbers") <elevenkb>identity: now, I read that section before asking the question but I think the phrase "we add a revision number that we increase each time we upgrade to a newer <elevenkb>snapshot" is ambiguous. It should really say "each time we upgrade to a newer snapshot with the same version number." Of course I was able to guess in that direction before asking my question since I was inclined to say "no," but still that phrase is an incomplete instruction imho because you have to infer from context.