IRC channel logs
2025-01-26.log
back to list of logs
<jakef>the build takes about an hour so it's slow trial and error <ekaitz>we should write a tool to query the guix codebase <ekaitz>like: gimme all packages with cmake-build-system that have special phases <ekaitz>jakef: in audacity we fix the RPATH with a patch on the CMakeLists.txt <coyotes4ys>0ad barely used 1/4 of my processing power,, pretty cool with pentium silver four core <jjba23>i am off to bed y'all, tomorrow new day, new chances to get that meson build working. I think i got it almost there, but it's calling the wrong meson target or so, but all libs there <jjba23>thanks ekaitz , stay in touch man, no seas timido di algo jeje bona nit <ekaitz>i'm an old man with a beard (not that old) <jjba23>porque no hay emoji de risa aqui porque sino <ekaitz>keep me posted with the package definition <PotentialUser-24>I would like to create a manifest file for a project of mine. However I require a package that is not provided by guix. Fortunately it can be "guix import"-ed. <PotentialUser-24>How would you approach this situation? Can they both co-exist in the same file? <ekaitz>PotentialUser-24: i think you can mix <ekaitz>or even better, make the package and send it to guix :) <potatoespotatoes>okay, more pressing question: how do I quote/unquote correctly to get this package metafunction to work? <potatoespotatoes>currently `build` evaluates correctly for the package name, but in the modify-phases function `build` becomes unbound. <jaft_r>potatoespotatoes: you'd probably want to use ,build to unquote it as everything after your grave accent will be quoted. <potatoespotatoes>ah! I missed that, thank you! apparently I need to collect garbage -- but that would definitely do it. I totally missed that, sneaky! <potatoespotatoes>time using guix: 1h, time writing a derivation for my bootloader: 1month. <ieure>Is there any way to get Cuirass to tell me why a build is failing? I regularly end up with builds in "Failed (dependency)" status, but "Dependencies" contains only "—" (an em dash); "Log file" is also "—". <ieure>Very disingenuous that it says the problem is with a dependency, but won't tell me what dependency or what problem. <apteryx>lilyp: I've just pushed the fix for the gnome-boxes redirection thing. I've tested it works on master <hatim>I have recently done a guix pull, and updated. Started getting weird issues. guix system: error: error parsing derivation `/gnu/store/zjs21lh9an6zs0wvgd9p758zwkz5pz9f-efibootmgr-18.drv': expected string `Derive([' <hatim>when I cat the file, its empty <hatim>Is anyone else getting this type of error? <apteryx>hatim: I'm not seeing that. perhaps your drive is having issues/or a corrupted file system? yo can try deleting that file in the store using 'guix gc -D /gnu/store/zjs21lh9an6zs0wvgd9p758zwkz5pz9f-efibootmgr-18.drv' and try your 'guix system' command again <apteryx>efraim: the 'make check TESTS=tests/crate.scm' fails on crate-import-only-yanked-available; perhaps you'd know what is going on? <apteryx>would it make sense to use 'use-modules' instead of define-module for test "modules" which are *not* test modules? (their name don't match their file name, which renders the REPL useless, and easier to copy a use-modules snippet in the REPL). <apteryx>at least from my experimenting in Geiser <sneek>Welcome back efraim, you have 1 message! <sneek>efraim, yarl says: Hi, "guix build -v3 --target=aarch64-linux-gnu -c1 llvm-for-mesa" fails on me with "llvm-tblgen: Unknown command line argument '-gen-vt'." any idea? <efraim>does llvm-for-mesa normally cross compile? <meatus>I tried disabling tests and nothing changes, perhaps it is some wierd submodule thing? <iyzsong>meatus: how did you disable the tests? you can try '-DBUILD_TESTING=OFF', or look CMakeLists.txt to see how. <meatus>iyzsong: thanks, found the option in CMakeLists <efraim>found it! I added '-yanked' to the file-name of yanked crates but didn't adjust the tests <futurile>I'm a social media engine promoting the survey results - my spamming of the #guix tag will continue! <efraim>I think I fixed cross-building llvm-for-mesa but I need to make sure it doesn't cause a world rebuild <efraim>and I should see if it's needed also for cross-building other versions of llvm <efraim>spoke too soon, building llvm-config tried to build a native version of llvm for some tools <efraim>yarl: I saw your message, the llvm-tblgen error is from using llvm-15 to try to build llvm-for-mesa using llvm-18 <efraim>yarl: for llvm-for-mesa? or for cross-building llvm itself? <yarl>I tried cross-compiling llvm <yarl>I tried by removing -DLLVM_TABLEGEN <efraim>according to llvm's documentation that'll cause it to also build a native copy of llvm for the tools it wants <yarl>I need to mention I don't know much about these. <efraim>I only know that much from reading the same page :) <efraim>we don't have an LLVM_NATIVE_TOOL_DIR though <yarl>Right. But, Is it not necessary to "build a native copy of llvm for the tools it wants" ? <meatus>Is there a package that contains 'msbuild'? It doesn't seem to be in mono <efraim>ideally it'd use the version we gave it, since we've already built it some other time <yarl>efraim: Maybe the problem is simply to use the same version then? <efraim>that was my idea, to use llvm-18 for llvm-for-mesa, but then it broke on building llvm-config with what looks like the same cross-compile failure that regular llvm has <efraim>so if we fix that we're doing well <yarl>Well, what are your changes? <yarl>Did you only made changes to llvm-for-mesa? <efraim>my first change was to replace the configure-flags for llvm-18 with the same flags from llvm-15 <cow_2001>i have sent a patch to the emacs-greader package on guix-patches mailing list <meatus>Is there a plan to make the system/home service library more scalable? I feel like documenting every service in the manual isn't sustainable <yarl>efraim: Do you get "Host compiler must support std::atomic!" error? <cow_2001>i have sent a patch, it was the wrong version number, so i have sent another patch, which had the right version number, but that version was the previous one, not the latest on elpa, so i have sent a third and last patch. sorry for that <yarl>Hmm, that's how llvm-18 with llvm-15 configure flags fails for me. <yarl>efraim: When does it fails on you? did you make some progress? <yarl>Do you need to set both LLVM_TABLEGEN and LLVM_NATIVE_TOOL_DIR? doesn't the latter sufficeN <efraim>I think I tried with just LLVM_NATIVE_TOOL_DIR and that wasn't enough for tblgen <meatus>sorry if it's a dumb question, but how do I close a debbugs thread? i sent a patch a while ago that I realize is completely messed up and I want to close it <yarl>efraim: Trying your patch. <yarl>efraim: Ok it compiles :) <yarl>I am trying without LLVM_TABLEGEN, just to be sure. <yarl>Now it doesn't with the "Host compiler must support std::atomic!" error. <efraim>I might also have fixes for llvm-16-19, just need to test them before and after <efraim>give it a few minutes, it'll complain later about std::atomic <efraim>it starts building but then it complains later into the build <yarl>Well, with the patch you gave me I can cross build 18 fine. <yarl>I just tried without -DLLVM_TABLEGEN to be sure it is needed along with -DLLVM_NATIVE_TOOL_DIR. <yarl>But it is indeed needed. <yarl>You say you got the std::atomic error with the patch you shared? <efraim>I got the error again when I tried without LLVM_TABLEGEN but with LLVM_NATIVE_TOOL_DIR <yarl>May I suggest not relying on this-package in what serves as base-llvm? maybe we can (define (llvm-configure-flags this) ...) which we call inside each llvm-* definition with this-package. <efraim>I think eventually we'll either factor out the configure-flags and the phases or turn llvm-15 into base-llvm and then have everything inherit from that <efraim>with one base-llvm that everything inherits from, depending on its own version being passed into it, this-package will work as expected with each version <yarl>efraim: May I be of any help? <efraim>thanks. it does end up being one of those things that moves so much around it's easier to do as peer-programming in person though <efraim>I figure if I can get llvm-15 to inherit from base-llvm without anything changing then I can leave everything as-is and adjust packages one at a time <efraim>avoiding the rebuild is always the big thing <efraim>right now I'm waiting on several versions of llvm to finish building so I can commit everything and move on to that stage <yarl>Ok. please ping me when you want me to step in for testing or something or when you commited. <janneke> apteryx`: yeah, had the same with core-packages-team, it was freshly rebased on master but the commit was unknown <janneke>could be that we're missing something? <cbaines>apteryx`, that commit it links to does seem like it should be known to the data service, but it isn't <cbaines>the commit both before and after are known <cbaines>maybe this is some bug/issue, or it potentially could be down to the issues with Savannah around that time <efraim>doesn't look like I can have llvm-18 use make-llvm since it'll mess with llvm-for-mesa for i686-linux <yarl>efraim: make-llvm is a new function you define, I guess? <yarl>What do you mean "it'll mess with llvm-for-mesa for i686-linux"? <efraim>currently llvm-for-mesa inherits from llvm-18 which inherits from llvm-15, so if llvm-18 changes then llvm-for-mesa changes too and that'd cause too many rebuilds for i686 <yarl>efraim: is it possible to condition the version on the host system? <cbaines>apteryx`, hmm, confusing. It looks like it couldn't talk to the guix-daemon for a short period, but then was able to <cbaines>I've checked the logs on the machine and I couldn't see anything related <cbaines>janneke, ideally the data service wouldn't have any gaps in the data, but unfortunately it's still possible for it to get stuck processing revisions, which can lead to some revisions being missed <yarl>In order to get it, I will ask a -simple- stupid question : To avoid triggering too much rebuilds on derivation servers we refrain from fixing sources? please no offense. <efraim>yarl: it might be possible, but it'll be far easier to just leave it as-is <efraim>we do end up sometimes leaving things in even if they're wrong or not optimal since fixing it would cause too big of a rebuild <yarl>oh. well it's very frustrating, I guess I'll have to get used to it. My problem is that I would like to use guix on some arm board and I can't really afford native-building mesa. <efraim>adjusting cross-building is generally ok, so you should be able to do it after I push the changes <yarl>So you are pushing some changes anyway? <efraim>yeah. the goal is that native builds will remain unchanged and cross-builds will start working. <efraim>I'd like to clean up llvm-18, but that'll cause rebuilds for native i686, so some of it needs to wait for another time <yarl>I see. would you be so kind as to tell me when you have pushed? <yarl>And thank you a lot, of course! <janneke>cbaines: just a few more steps to our ideal world, right? ;) <cbaines>janneke, at least one next step I've identified is to rework how the data service inserts data, if it can happen in parallel rather than one revision at a time, that should increase throughput as well as reducing the chances of one revision holding up another <apteryx`>our manual still mentions somewhere that desktop environments default to xorg; that's false at least for GNOME <apteryx`>gdm has wayland set to #t by default; does this impact other desktops choice of session as well? <apteryx`>I guess it causes GNOME to use Wayland when it's set, and others lacking support for Wayland such as XFCE will use Xorg nonetheless <apteryx`>cbaines: I've rebushed the elogind-updates branch on tha last known revision, fingers crossed! thanks for the info <cbaines>apteryx`, great, one other thing to note is that data.qa is setup to focus on the branches that are next to be merged, that's why just go-team and xorg-updates are showing at https://data.qa.guix.gnu.org/ <cbaines>so the comparison for elogind-updates will still be missing until it moves up the queue <yarl>efraim: Thank you, I'll take a look! <jonsger>ACTION does not understand why his Guix System does not boot anymore. After entering the LUKS password for the first time it ends up in the GRUB shell. Manually booting starts the kernel and asks the second time for the LUKS password. After that it ends up in a Guile REPL. `(quit)` exit its boot "leads" to a kernel panic :( <rubuj-eto>Hi! After my installation, I can't add as root a ".xkb" file in directory "/gnu/store/...-xkeyboard-config-2.38/share/X11/xkb/symbols". The goal is to use a keyboard layout, which is not before the "xkeyboard-config" version 2.42. And I can't change a directory permission with "chmod" even as root. Does anyone any idea about this problem ? <Rutherther>rubuj-eto: you shouldn't touch the store manually, ever. It's a good thing it isn't possible easily. You need to make a new package that will add that file <hatim`>Run `guix gc --verify=contents`, it might take sometime. Since doing a guix pull a few days ago, my system ha broken, and I have a number of .drv files that are just empty. All of these related to the EFI/GRUB/Bootmgr. Have not fixed it yet. <jonsger>is there any tutorial, for how to use the guile repl in the boot process? It always says "no code for moulde XY" <jonsger>ah, ,bournish looks like a useful command :) <[>How do I replace the ping in /run/privileged/bin with iputils ping (rather than inetutils ping)? I added (privileged-program (program (file-append iputils "/bin/ping")) (capabilities "cap_net_raw=ep")) to my operating system definition, but /bin/ping is still inetutils ping <[>(Removing inetutils ping from %default-privileged-programs worked) <df>is there any provision for normal users to use wireshark (as with debian's wireshark group), or does it need to be set up manually? <rubuj-eto>Thank you for your help. On Guix, the last "xkeyboard-config" package version is 2.38. On my "guix-profile", there is a symbolic link "X11" that points to the same directory name in "/gnu/store/". So I can't add my "xkb" file, even on my Guix profile. Could you explain how I can "make a new package that will add that file" as you said ? <df>and unrelatedly, if the guix source dir is in my geiser-guile-load-path, should I be able to use geiser's features on my config.scm (which is in /etc)? <rubuj-eto>Rutherther: Do you think I have to create myself a new package ? <df>although actually, I'm not sure I even have geiser set up properly for the guix source itself... <df>I don't seem to be able to navigate around it <Rutherther>rubuj-eto: yes, the process of making something that produces a new store path is called packaging <Rutherther>you can of course start from an already existing package and modify it, or just copy contents of original package and add a new file <Rutherther>but in your case it might be easiest to just update xkeyboard-config <rubuj-eto>Rutherther: Thank you for your advices. I will work on this problem <df>ah, I think I have sorta solved my geiser issues, although the fact that I'm using tramp on config.scm confuses matters a bit <df>(I'm now aware that there's no reason for config.scm to be owned by root, it's just a leftover misunderstanding I haven't fixed) <wakyct>yeah df I remember getting confused on that when I installed the first time <hatim>How do we delete .drv files and force them to be rebuilt? I have /gnu/store/zjs21lh9an6zs0wvgd9p758zwkz5pz9f-efibootmgr-18.drv which, is empy when I cat it out. But the final outputs. Running `guix build --derivations efibootmgr' returns "/gnu/store/zjs21lh9an6zs0wvgd9p758zwkz5pz9f-efibootmgr-18.drv". When I run `guix build --no-grafts efibootmgr', it returns a store directory with the built efibootmgr. But running `guix build <hatim>efibootmgr' or `guix build --repair efibootmgr' returns an error. "guix build: error: error parsing derivation `/gnu/store/zjs21lh9an6zs0wvgd9p758zwkz5pz9f-efibootmgr-18.drv': expected string `Derive(['" ... So I think efibootmgr must have been built with no grafts before the corruption. Is there a way to delete the .drv and force a clean build. I think efibootmgr is "live".. <Rutherther>hatim: yes, guix gc is a command that allows you to delete files in the store <hatim>The issue is that those files are "live" and when I run guix gc -D, it doesn't work. It's part of my system generation 4. I have booted into generation 3 from the grub menue, and when I try to to do guix system roll-back, it complains that efibootmgr is empty, and was expecting "Deriv([". So I suspect I need to either somehow delete that latest system generation without for me to be able to do guix gc -D. Feels like a chicken and egg <graywolf>Hello Guix :) Any hints on using Geiser together with guix shell -Cm manifest? I cannot get it working. It works with --pure, but not -C. <hatim>doing guix gc --delete-generations does not work as its the current system, unless I can remove the symlink manually. For some reason guix system-rollback is reading efibootmgr-18.drv, and failin <hatim>guix gc --verify=contents does pick out a number of other files, including efibootmgr. I am now going to try guix gc --verify=contents,repair. I was hesitant to do as the manual cautioned <wakyct>hatim what is depending on efibootmgr-18.drv? If you delete those files then you can delete the drv <hatim>doing 'guix gc --verify=contents,repair' has reduced 24 empty .drv files to just 6!. The remaining grub ones 'cannot be repaired'. But I was able to do a system roll back, and gc delete the other 6. guix gc --verify=contents, returns. Now to try to build the system. again.. Thank you @Rutherther <hatim>Thank you, got a new clean system generation. <noe>guix system: error: #<<search-path-specification> variable: "GUILE_LOAD_PATH" files: ("share/guile/site/3.0") separator: ":" file-type: directory file-pattern: #f>: invalid G-expression input <noe>Is there anything I can do about this? I need to run evaluate-search-paths on a package to set the guile load path in wrapped-dbus-service. <civodul>noe: search paths are records so you cannot insert them as is in a gexp (records cannot be serialized) <civodul>instead you have to use ‘search-path-specification->sexp’ and vice versa <civodul>see guix/build-system/gnu.scm as an example <jmes>Ah, that's funny I was having a similar issue but with a record of my definition. I was stumped until just now <noe>I was confused because (guix)G-Expressions says for ungexp: «If OBJ is another kind of object, it is inserted as is.» <jmes>My issue is that I can't use records as fields in a service configuration. I guess because the configuration is a gexp at some point (still fuzzy on the internals). <jmes>I'm guess that's also why define-configuration is the way it is, to avoid being a record outright