IRC channel logs
2024-03-03.log
back to list of logs
<ekaitz>it tries to fill with a lang and not with other interesting things sometimes <whomst>sorry about the late response but i gave up trying to export a local build since i need a channel anyways <whomst>now i'm hitting a cryptic exception in the guix pull command <whomst>it might be broken because i've set the channel url to be an absolute path on my filesystem and not a url <whomst>"(exception misc-error (value #f) (value "no code for module ~S") (value ((test-1.0.0))) (value #f))" <whomst>is there a way to specify a ssh key for git operations on a guix channel? <freakingpenguin>When I used a local channel I needed to use file:///path/to/repo, not use /path/to/repo. <whomst>what's really weird is the output of `guix pull` doesn't have any spaces between the channel name and the path <whomst>there is more after home but i ended it there <whomst>the full file:// URI points to a repo that's (hopefully) valid <whomst>is there some way to print what throws this exception in the guix pull outout? <whomst>i have a pretty high verbosity (-v8, not sure if that's a valid log level but it appears to round down) and it just prints the log contents to the stdout/stderr instead of adding more information <whomst>nvm that's only for guix build, not guix pull <whomst>i did find --debug which seems useful <whomst>that didn't really help. it's trying to access /gnu/store/[...]-variant-packages.drv and it failed in some containerized process there <whomst>none of the packages in this channel are currently installed (and not having any packages in this channel still causes the failure), so i'm thinking there's some issue with the channel metadata (either in my .config/guix/channels.scm or the git repo) <whomst>actually let me investigate the no-packages case. i think the error is different <whomst>i made a guix repository without any packages and guix pull succeeds <whomst>at this point i'll just split up my integration tests to check the channel without pacakges and channel with packages <rfb>I was considering putting together a package for kopia (github.com/kopia/kopia). It was simple to generate the initial package, but it requires around 15 other go packages which are not yet defined. I used go license checker, and all the dependacies appear to be be BSD/MIT or Apache licenses. Before I go to the trouble of creating all these packages, how likely is the guix team to accept these changes upstream? <mange>Are there any committers online who can quickly fix a dumb mistake I made? In bca48fdef48150a3c4e96e3941feb1986ea3e631 I refactored some prosody packages, but that accidentally changed "prosody-smacks" to "prosody-smack". I'm hoping someone might be able to fix this typo quicker than full patch review. :) <whomst>the package name/package file was test-1.0.0 since i want to pin on exact versions <whomst>renaming that to just "test" solved my issues <gerogaga>Hello, is there some programmatic way of getting .so files? Either via environment variables or otherwise. <Guest17>what do you mean by getting can you clarify <Guest17>well there the ld cache and there is the ldd command and the known paths <gerogaga>I have a common lisp project that needs libcrypt.so as a dependency but cffi can't find it. <Guest17>in that case maybe look pkg-config and the files in /lib/pkgconfig/ <Guest17>but if ffi (I'm not familiar with common lisp) can't find then probably ld doesn't know about it <Guest17>btw i have no idea how you would parse ld.so.cache <gerogaga>ld not knowing about it is a bit more concerning <Guest17>I had the same problem with guile ffi but the problem there was that I was using guix+arch and I was trying to use the libraries installed by arch with the guile that was installed with guix <gerogaga>Oh, I found the issue. I was using my global install of SBCL, not the one in the shell. <hapster>hi guix! I am trying to debug on the basis of dmesg messages. Is there a way I can set kernel module parameters programmatically, that is, in my "configuration.scm"? <hapster>Also, some days ago I asked about tips regarding the installation of an ancient Lenovo x121e. I finally found the issue myself: in BIOS, it has a setting to automatically choose between GRUB and EFI. I had to choose "EFI only" because otherwise BIOS would pass GRUB even though I used an EFI-configuration. If you've got questions, you can ping me or @hapst3r <Guest17>you can use kernel-arguments field in oprating-system <Guest17> (kernel-arguments (append '("resume=/dev/mapper/cryptroot" "resume_offset=84201472" "pic=noaer") <hapster>Guest17: Thanks, thats good to know! <Guest17>also if you want to change kernel arguments over and over again to test something using grub to change the kernel args temporarily for that boot might be nicer, to do this just press e in grub menu and you can edit the selected item and C-x to continue <jpoiret>heh, GHC is actually longer to fully "bootstrap" than rust <graywolf>If there are two programs that need the same patch (for a vendored component), how should I do it? guix lint insists that the patch should start with program name, so the correct choice is to cp the patch into a separate file? <graywolf>Also, separate question, is it a problem is I keep forgetting to add my name to copyright lines at the top of the files? <graywolf>oriansj: Should I sent a patch adding it in all applicable places? <graywolf>(But if no reviewer told me to do so, maybe the changes just were small enough?) <oriansj>well; that is a different question. To which I am not sure I have a good answer for you. As generally your work should have included your copyright with the changes. <oriansj>and I doubt anyone is going to make a point of fixing it if you didn't care enough for it in the first place. <graywolf>I personally do not care much (therefore I keep forgetting) since all the info is in git anyway, but project seems to care, hence my confusion. I guess I will just try to pay more attention to it in the future. <PotentialUser-60>I am trying to build rock64 image and got stuck with build fail for gawk-mesboot-3.1.8.drv. Any tips for me to get moving would be appreciated. <Franciman>yesterday i installed guix on a new pc in 2mins :P I just copied the config over <podiki>my last install i just had the hard drive and ran guix system init on it (mounted on my guix machine) <Franciman>i just have to understand how to deal with extra channels <podiki>though took me forever to deal with some bootloader issue that i think was just a parititioning issue <podiki>in terms of having an install already have extra channels setup? <podiki>definitely has come up here before, a little service that people can have in configs to do that for general channels/sub servers i'm sure would be useful <jpoiret>graywolf: wrt. patches, it's fine if the patch starts with the name of *one* of the packages it applies to <graywolf>jpoiret: K, will do it like that, thank you :) <podiki>speaking of patches, any opinions here (will ask on guix-devel) about when updating packages that all need to be done at once? <podiki>since they share a version number variable, as soon as that is changed all of them will fail to build (source hash), but it is a lot of nontrivial changes to do in one patch <podiki>i guess we go as in this series, one at a time, pushing all at once (maybe a note on first commit that the following n commits are needed) <jpoiret>damn, we need a cross powerpc toolchain to build qemu on x86_64? wild <jpoiret>podiki: I guess this kind of breaks the idea of atomicity for `git bisect` though. <podiki>yeah, both approaches have downsides <jpoiret>but yeah, I much prefer a readable commit log to an atomic one <PotentialUser-60>I am trying to build rock64 image and got stuck with build fail for gawk-mesboot-3.1.8.drv. Any tips for me to get moving would be appreciated. <podiki>my instinct here (or taste?) is to accept that some packages will be broken on a commit but are immediately fixed (we do this accidentally all the time :)) <rimarko>hello, is there a way to keep a build tree even when guix build ends successfully? <jpoiret>rimarko: not right now, I think there was a patch on the MLs for that at some point <jpoiret>in the meantime you can just force the build to fail by adding a dummy failing phase <rimarko>a phase with a lambda that returns #f? <graywolf>phase contaning only (lambda _ (error #t)) will do <graywolf>I am not sure if return value of phase does matter <graywolf>I see #t at the end of phase, but not very often, so ¯\_(ツ)_/¯ <rimarko>graywolf yes in fact I've read somewhere that it's not needed anymore, though I see it's still recommended in the cookbook <nckx>Return values are ignored. The #t is obsolete and should be removed when you can do so without adding disproportionate noise. <nckx>If the cookbook explicitly recommends it, it is wrong. <nckx>If it merely includes outdated examples, patches removing the #t are still very welcome. <jpoiret>the linux-libre deblobbing scripts are way too slow <graywolf>nckx: Cookbook states `The procedure must return #true on success.' <graywolf>`... Hence the trailing #true to ensure the right value is returned on success. ' <rimarko>I'll prepare a patch for that section of the cookbook re: return values <apteryx>jpoiret: should I merge my core-updates work already, or should we synchronize for the next world rebuild? <vivien>Wondering why why3 does not have support for coq… <vivien>configure: WARNING: You need Coq 8.7 or later; Coq discarded. <jpoiret>apteryx: hey! the pkg-config thing, or ld-wrapper? <jpoiret>I think we should let both of these simmer for the next core-updates, right after this one <jpoiret>whew, GNOME vm just booted on c-u :) <jpoiret>vivien: is it not trying to do a char-by-char comparison? <vivien>It looks like it, but in fact it has a range of coq version it supports, and that range ends at 8.16 <vivien>(it does not build with coq 8.17) <hapst3r>Does somebody have a working network configuration to share? I am trying a kind of "Linux from scratch guix edition" (no DE/WM, only %base-services), and I cant get a wireless connection to persist (I can get it to work manually with `wpa_supplicant -i $INTERFACE -c $CONF -B && dhclient $INTERFACE` but it's gone after reboot) <oriansj>hapst3r: I have an iwd wifi setup you might find useful <oriansj>although you may wish to skip the complete disabling of substitues as it adds quite a bit to the system setup time. <hapst3r>oriansj: thank you, that's really quite explicit :) <apteryx>are we going for a full rebuild still? at least the pkg-config propagation problem is going to annoy us on master for a while if we don't merge it, as I think meson has learned to generate pkg-config files with .private fields that it expects to be used only for static compilation (in other words, it expects pkgconf's behavior) <jpoiret>apteryx: I haven't had any problems regarding that for everything in the desktop.tmpl system config <apteryx>OK, perhaps it's rarer than I thought (mpv case) <jpoiret>yeah. it's nice that we should be able to get rid of that <ajarara>ik the idea is to build from source but this is an NPM package and I see there's an unsolved bootstrapping problem on the mailing list so I'm going to stick with prebuilt