IRC channel logs
2024-07-19.log
back to list of logs
<jackhill>I'm still curious about a generic way to learn more about a shepherd service <RavenJoad>jackhill: The fastest way I know of is to read the source for the service. As far as I know, shepherd does not have an easy way to do runtime CLI introspection. <Guest83>Warning (unlock-file): Unlocking file: Invalid argument, ~/Desktop/Emacs/Denote/dev/.dir-locals.el, ignored: The Emacs directory is a SMB share. Is locking not supported on a SMB share? <adi-lb-phoenix>So I have git repository . I want to be able to able to install my repo using the command guix install <myreponame>. I have cloned the latest version of the repository . I have found hash of it using "guix hash -rx ." This is my .scm code https://paste.debian.net/1323680. I want to be able to install the repository after executing the code. Need <jaft``>adi-lb-phoenix: put "my-hello" at the end of the file (so your defined package is the last thing returned) and then run "guix package -f the-file-name.scm" (in the directory the .scm file's in, of course). That should get you what you need. <adi-lb-phoenix>jaft`` here what does "my-hello" technically represent ? It is not the name of the repository nor a name of any file. I have just given a random name. Is that of any significance here? <jaft``>Nope; it's just a variable so, like any variable, you can name it anything. If you wound up trying to add this to the Guix repo.s to make it available for others, they'd probably ask you to name it to something more useful for organization/ease-of-readability; but it's just convention. Technically, you can give it any variable name you want. <adi-lb-phoenix>jaft`` Noted .So I ran the command as suggested. I got the error missing closing parenthesis <jaft``>Yeah; looks like you didn't close things properly. Looks like you need two closing parentheses on line 17. <jaft``>Sure; as long as it's in a pastebin (like the one you've been using), perfectly fine. <jaft``>O. K.; you're close but you still need an extra closing parenthesis on line 17. And, with that one added, remove one from line 25. <adi-lb-phoenix>jaft`` error: (method git fetch): invalid field specifier . I received this <jaft``>Ahh; I know what it is. Lemme find one of my files last time I tried packaging something… <jaft``>Yeah; you'll want to turn "git fetch" to "git-fetch" (with the hyphen), on line 12. Also, add the module "(guix git-download)" as that's where it lives. <jaft``>Also, it's going to complain about not knowing which commit to pull from. Have you tagged your repo.? Pulling from a particular tag'll be easiest. <jaft``>(though we can always pull from a particular commit, too; perfectly possible) <adi-lb-phoenix>jaft`` will (guix download) not be enough? what is the difference between (guix download) and (guix git-download) <adi-lb-phoenix>jaft`` I havent tagged the repo. So I should add (commit <hash_of_that_commit>) and place it inside the origin list right? <jaft``>I don't know what all else is in each respective module but I know that "(guix download)" has "url-fetch" while "(guix git-download)" has "git-fetch". You'd use "url-download" if you were downloading an archive file which contains the source code. Since you're pulling from a repo., you'll want "git-fetch", instead; hence needing "(guix git-download)". <jaft``>Yep; specifically, you'll want to place it inside "git-reference" (which is, indeed, inside of the "origin"). <adi-lb-phoenix>i get "hint: Did you forget a `use-modules' form? I have placed the (guix git-download) as ( define-module .... (guix git-download)) <jaft``>Did you get something like "error: cmake-build-system: unbound variable" before the hint? <adi-lb-phoenix>I was observing that. Do I need to be aware of anything while using cmake-build-system ? <jaft``>No; at least, nothing major. Swap "(guix build-system gnu)" for "(guix build-system cmake)". <jaft``>You'd want "(guix build-system gnu)" if you were using "gnu-build-system" but that's not the case, here. <adi-lb-phoenix>tried "build-system gnu" and "gnu-build-system". I got the same error as mentioned above <jaft``>Oh; I'm assuming you want to use cmake so you should leave "cmake-build-system" as is. You want to swap the reference to the "(guix build-system gnu)" module with "#:use-module (guix build-system cmake)". <jaft``>Looks like your hash doesn't match up. I'm guessing you must've changed it recently? The one you originally shared works, for me. Oh; unless you're not using the latest commit, maybe? I plugged in commit "473274aa4df13657080744ee6ebc779e21809535". But, basically, the gist of the error is that the code Guix pulled doesn't match the hash you provided. <jaft``>Without changing anything else, you can bypass it by changing what's in base32 with "0dpkfaazml2sml0b2kgncq4gl5izyyx5jp8krrfm0wj49v0pnxlw", instead of "0pyg7f4dk9h3y2r60qmaqr2pmj3jk18f1dwjdi5glfb4szab3hny". <adi-lb-phoenix>I just want to build it now for the first time. I changed the content in base32. The output https://paste.debian.net/1323690/ . Do I have to build the .drv file separately. I Havent given any instructions of what exactly to execute after pulling the repo. <jaft``>Nope; that's for Guix to handle. You will want to check out the error log (/var/log/guix/drvs/l1/26rsz7yj9m68db0rmcp8qg1dksdfdd-llama_lisp-1.drv.bz2); that'll have details on what went wrong. <jaft``>I may be able to help less, here; I don't have much of any experience with either C or CL. But, in general, Guix tries to make building easier by it knowing how to handle various types of builds. In theory, you select the appropriate build type and that build type will know the relevant files it needs and just do the right thing. <jaft``>(so, for example, "gnu-build-type" will try to run ./configure (if it exists) and, then, "make" because that's how that particular build type tends to go) <jaft``>There are always edge cases and you can modify the phases that get run to try and deal with those but, like I said, I'm less familiar with this build type, if we need to do more than, say, provide some dependencies. <adi-lb-phoenix>interesting . I see. I see . I will read more on it and get back. Thanks a lot jaft``. I really did learn basics of guix more cause of you! <jaft``>Sure thing! Always happy to help, if I can. <Guest98>Hello! I am curious if anyone can assist me in printing the value of %base-user-accounts via the guix repl? <jaft``>I think the hash doesn't have enough characters to be a base32 hash. I noticed it only has 51 characters while the ones we were working with, before, are 52. Perhaps you missed a character? <jaft``>adi-lb-phoenix: 👆️ (forgot to tag you) <lilyp>hmm, I get too many authentication failures on git pull – did something change? <adi-lb-phoenix>I am inserting "(license apache)" at the end . But when i do "guiz package -f filename.scm", I get an error saying "error: apache: unbound variable". How can I write licenses properly in the .scm installation scripts? <jaft``>adi-lb-phoenix: I'm not sure if it's in the documentation, anyway, but – looking in the modules file, in the Guix repo – it looks like the variable names are asl1.1 and asl2.0 (for versions 1.1 and 2.0, respectively). <adi-lb-phoenix>Also to build a repo from scratch and be to install it using the command "guix install repo" can I use the above link and recreate thr tutorial? <jaft``>adi-lb-phoenix: If you wanted to install your package without using "guix package -f …" (or using "--install-from-file=", instead of "-f"), you'd have to add your package definition to a channel (whether the Guix channel or your own); I don't think the tutorial I linked to covers that (notice it uses "guix package --install-from-file=…"). <adi-lb-phoenix>The aim is to be able to do "guix install repo_name" . So approach I am following now is, Try to build locally by using the .scm program. After that create a channel and do guix pull. <jaft``>Makes sense, to me; that's probably how I'd tackle it, too. <Kabouik>I am trying to use ./pre-inst-env in my clone of the Guix git repository to test my package definitions, but I am getting: "/home/mat/Projects/guix/guile: error while loading shared libraries: libguile-3.0.so.1: cannot open shared object file: No such file or directory". Any idea what could be wrong? This happens both in my environment or in a guix shell after ./boostrap and ./configure. <glenneth>Hey Folx. I'm running gnome on guixsd and I want to switch to swaywm. Having problems with network access though. I can't run any sort of git command and I can't access smb shares on my network. Everything works just fine under gnome though <glenneth>Looking for suggestions as to what may not be getting loaded under sway. I'm dropping to tty2, logging in and running exec sway from the cli <jpoiret>glenneth: networkmanager is probably not set-up, depends on how you switched from gnome to sway <jpoiret>do you have %desktop-services in your system config? <jpoiret>Kabouik: i'd do `rm guile scripts/guix` then make again <Kabouik>jpoiret: are they regenerated by ./bootstrap and ./configure? <glenneth>jpoiret: I do. I can post my current system config if that would help <jpoiret>glenneth: can you even ping some adresses? <Kabouik>I may not have understood the correct workflow then. What I did is (1) git clone Guix, (2) edit gnu/packages/terminals.scm with my changes, (3) guix shell -D guix --pure, (4) ./bootstrap && ./configure, and (5) ./pre-inst-env guix build fzf. But now after deleting the scripts and doing all that again, I get "./pre-inst-env: line 55: exec: guix: cannot execute: Is a directory", I don't think that's expected <Kabouik>So if I add make to the step (4), is that the correct workflow? <Kabouik>make failed because makeinfo command is not found (in the guix shell) <jpoiret>huh. is your external guix up-to-date? <jpoiret>ie. the one you call with `guix shell -D guix`? <Kabouik>I may not understand, does that mean my "real" Guix? I haven't reconfigured in a few weeks. I can try that. <lilyp>guix pull ought to suffice, but you really should reconfigure more regularly ;) <Kabouik>My latest guix pull was a couple days ago, or yesterday <jpoiret>i never remember which package provides makeinfo, is it texinfo? <jpoiret>welp, I have texinfo in the shell you posted <Kabouik>There was an issue with po4 in the make output too as far as I remember, before makeinfo. Cannot go back that far in the buffer now because I'm reconfiguring. <lilyp>Am I the only one who gets authentication failures from Savannah SSH? <jpoiret>Kabouik: at that point i'd do `git clean -dfX .` and start over <pranavats>Hi. Does anyone have a working package definition for Opentoonz (2D animation software)? <adi-lb-phoenix>So I am using a cmake build system to build my repo. This https://paste.debian.net/1323709/ contains the input fed to the cmake-build-system. What exactly do these mean and how do I install all the other packages that are needed by the repo. How can I give installation instructions.? Such as creating an environment, executing commands a certain <jpoiret>adi-lb-phoenix: wdym executing commands in a certain way? <jpoiret>your CMake configuration should be able to build and install your project in the usual way <adi-lb-phoenix>jpoiret so where do I give the cmake configerations? Should they be in the arguments and the input field? <pranavats>I guess that makes it unfit for including in guix at all, atm. <theesm>hi guix, does anyone else have connectivity issues to debbugs.gnu.org, savannah and linux-libre.fsfla.org or is something broken on my end? <lilyp>savannah now gives me a refused connection, so it's not just you <jpoiret>adi-lb-phoenix: don't you have a CMakeLists.txt? <Kabouik>`git clean -dfX .` fixed it jpoiret, thank you. My attempt at upgrading the fzf definition failed, though. <Guest17>using guix package --roll-back and guix install/remove gives me this error i can use guix with other users without any problems <Guest17>also when i run guile the variable make-custom-binary-output-port is bound inside the (ice-9 binary-ports) module can someone help me with this issue <adi-lb-phoenix>jpoiret so the repository has CMakeLists.txt. Should I add them to propagated-inputs in the .scm installation program ? <wehlutyk>I'm trying to get emacs running on a reMarkable2, which last year had two problems <wehlutyk>on one side, building rust on armv7 is currently stuck because it <wehlutyk>isn't yet working under Guix as far as I know <wehlutyk>which make me wonder if rust cross-compilation would become a topic? <zimoun>Am I the only one not able to “git fetch” from Savannah? <zimoun>“fatal: Could not read from remote repository.” <lilyp>nope, I asked about that earlier <Franciman>i'm making fun of all my colleagues who usually make fun of me for using guix <Franciman>civodul: i submitted the paper citing Guix System for the experiments! :) <jackhill>fun thing for me: work requires crowdstrike, but since they don't have a version that works with Guix, I got an exception (much to me delight)! <Franciman>a paper on knowledge representation and reasoning <zimoun>Or the world mess is just a cover for an attack against free software by proprietary software. Conspiracy! <Franciman>and was also able to have a reproducible environment <ieure>Someone should just put whatever thing is down in the topic. <jackhill>Anyone have examples of a system configuration that uses u-boot's EFI facilities to chainload grub-uefi? I'm curious about using Grub's LUKS functionality for instance. <lilyp>Franciman: oh, you have a DOI or a preprint? <zimoun>civodul: thanks. That’s weird, my laptop doesn’t connect to it but all the rest is fine… Hum?! <efraim>I might have to merge the rust-team branch slightly blind. if ci.guix.gnu.org says it looks good that might have to be enough <civodul>efraim: i think core-updates was first, no? <efraim>there's been a couple. core-updates is looking better though <efraim>perhaps next round on rust-team I'll go through and try to make everything use a newer rust-cbindgen and other crates that always seem to just use the then-newest versions <efraim>its "not the way upstream does it" but it should speed up building if there are fewer duplicate crates with different versions needing to be built <Deltafire>what does this mean, at the end of the unattended-upgrades.log: guix system: error: no matching generation <Deltafire>seems like everything went okay apart from that error <efraim>I get that too sometimes and haven't had any issues <civodul>Deltafire: it’s fine: that’s because it tries to delete old generations at the end, and in this case there were none to delet <lilyp>Is it expected that glib rebuilds after everything that happened? <lilyp>okay, no, it turns out i hade a super world rebuild on my master branch <efraim>civodul: I limited it to x86_64 to not overwhelm the aarch64 build machines. It's been pretty much ready for months, that's why I was thinking of jumping the queue <civodul>hopefully we can finish ‘core-updates’ and merge it afterwards <lilyp>civodul: what's doxygen on core-updates rn? <civodul>on ‘core-updates’, the main issue right now is libfaketime segfaulting in the ‘nss’ tests <civodul>lilyp: doxygen builds fine on ‘core-updates’ (x86_64-linux at least) <dthompson>initially it was going to cause 3k rebuilds, but that was because shepherd referred to guile-3.0-latest. I sent a follow-up patch to fix that <efraim>I might mess with qemu and qemu-minimal more to reduce the inputs to qemu-minimal to only firmware that's actually used on that architecture <lilyp>If it's 1.11.0 I've made an independent discovery; if not, I'll have to wait and submit <dthompson>civodul: thanks for looking! want to make sure what I did for shepherd is OK <dthompson>hmmm I haven't pushed in awhile and now I get "unknown introductory commit and signer"... gotta look into what I do to fix this <zimoun>dthompson: yeah I find the message unhelpful, then Section “guix git authenticate” in the manual does not help much. Then the helpful section is Building from Git. <dthompson>hehe I am reading the guix git docs now... I will move to the other section <dthompson>this has just been working for me for so long that I haven't thought about it in years lol <zimoun>well, display commit 9edb3f66fd807b096b48283debdcddccfea34bad and associated signature would help, IMHO <zimoun>I mean when invoking “guix git authenticate”. <dthompson>alright, I'm good now. pushed guile 3.0.10 upgrade! <civodul>z572`: i posted a French translation :-) <z572`>civodul: Thanks, I sent the v4 version, If it's okay, I'll push it <efraim>ugh, the always annoying bit. I put the (if (this-package-input "openbios-qemu-ppc") ...) in the main package and then tried to take the other branch from the inherited package <dariqq>anyone else getting an error during guix pull? It is failing to build guix-cli-core.drv with "unexpected kwarg syms ((#:key-type key-type #f)) (t1176)" <dariqq>i guess it is the guile-3.0.10 update? <civodul>freakingpenguin, dariqq: i reverted the offending commits so we can investigate without pressure <efraim>civodul: perhaps guile in (guix self) shouldn't be guile-3.0-latest if the other guile modules aren't built with it <civodul>efraim: maybe, but it should be fine <dthompson>civodul: strange! I did a 'guix pull' after and it worked for me. :( <dthompson>I wonder what I could do to catch this upgrade issue in the future. I can't explain why 'guix pull' worked for me but was clearly broken for others. <jaft``>the_tubular: looks like it's in the package "keyutils"; install that (or use it in a shell, etc.) and you should get access to it. <ieure>the_tubular, Are you on a way old Guix? I see it on a machine I haven't pulled on in months. <jaft``>Mmm; good point. That could be a cause.