IRC channel logs
2024-03-24.log
back to list of logs
<pfna>It's probably faux pas, but does anyone know in a config.mk if I can just add my own "re-assignment" to the bottom of the file, just to make things easier than regexing entire lines? <pfna>Ah, I can be explicit instead <pfna>if make is going to call cargo for me, do i need to add the guix build-system cargo module, or is a package alright? <pfna>NEVAMIND, we will see shortly <pfna>Trying to make a call to substitute*, but guix build tells me I've used the wrong type to apply. Here's an image that contains some context: https://i.imgur.com/f6uMpDK.png Do I need to be escaping something I'm unaware of, ehre? <pfna>Aha. Gotta pay attention and not wrap everything in parenthesis, perhaps. <pfna>New perplexion: I've got `#:use-module (gnu packages rust-apps)` in my (define-module) form, but I get an unbound variable error on `rust-cargo` in my (native-inputs) form. What am I missing? <monaho>How to work around python packages that rely on setuptools-scm to detect the version, but the build phase fails with LookupError because the guix checkout does not contain the .git directory? <pfna>Another question: The placement of #:usemodule calls doesn't matter as long as they're all at the top, right? <pfna>If it turns out this was because I wasn't guix pull'd I'll feel so dumb lmao <pfna>GUIIIIIIIIIIIIIIIIIIIIIX I was right <pfna>However, now we got some other problems here <pret7>Hello! How long does it take to get back the debbugs acknowledgement email with the issue ID after submitting a patch <bjc>normally just a few minutes, but if it's your first patch i think it needs manual approval to prevent spam <pret7>Oh I see, I've sent a patch before though <pret7>But that might have been from a different email address, I don't recall <pret7>Welp, here's hoping I didn't mess anything up! <pfna>Is there something that's restricting my cargo process from accessing the net? <pfna>(During guix's gnu system build) <stellarskylark>heyo folks, having a bit of trouble with my KDE setup. Applications installed on my home profile vis `guix home` don't seem to show up in the application launcher. I've checked and `.guix-home/profile/share` is in my XDG_DATA_DIRS so I'm not sure what's up <pfna>yes, stellarskylark. cargo's choking with "network failure seems to have happened" after "failed to get rawler as a dependency of package rawloader-clib" <bjc>there's no network available during build <bjc>it's completely isolated by design <pfna>Mm, so I need to instrument more of the cargo build in the package, presumably <pfna>doing some fetchin' presumably <bjc>if you need crates in your build, you have to package them, too. have fun with that. rust can take a looooooong time to package up <stellarskylark>because it can't download them, that would create determinism problems <bjc>they inherited some poor decisions from nodejs. namely, dependency explosions <stellarskylark>last time I stopped using guix was because I burned out so hard trying to update nushell <bjc>even simple sounding crates can have a hundred dependencies. it's a disaster <pfna>So modifying the cargo.toml isn't gonna help, right? <bjc>yep. i try to avoid rust in general, these days. the language is good, but cargo is just one long sequence of terrible decisions <stellarskylark>probably not, needing tons of dependency crates is endemic to the rust ecosystem <pfna>is it not as simple as wgetting them all and letting cargo build from local <stellarskylark>and that presents a problem in terms of workload for guix because of determinism <bjc>it's a problem for everyone because it's completely ripe for supply chain attacks <stellarskylark>I tried using Rust for a project and like the language is really neat but it didn't click with me very much yknow <stellarskylark>so anyway all programming languages are bad, use the ones you like <bjc>cargo is inherently insecure <jaft>pfna: it's not because there's no internet connection to ~wget~ them with, during the build process. Without diving into it, this is for reproducibility purposes (as I understand it). <jaft>stellarskylark: if you write the package manager to include managing an entire OS, you don't have to choose, of course; 😉 <stellarskylark>okay so I fixed my KDE plasma problem by just removing the .guix-profile directory entirely so now KDE apparently actually bothers to check .guix-home <stellarskylark>trouble is that my EMACSLOADPATH still includes the .guix-profile directory which has Broken It <stellarskylark>I understand that's generated on installation of the Emacs package, how can I rebuild/reinstall it so I get a correct EMACSLOADPATH again? <stellarskylark>ig I could symlink .guix-profile to .guix-home but that kinda sounds like I'd be asking for trouble <lilyp>cbaines: Since you went ahead and pushed most of Vivien's patches, may I push the rest? <decfed>I am using copy-recursively to copy store items into a build directory. It sometimes errors with "Permission denied". Are there any read-protected files in the store? What could be the reason for this error? <cbaines>lilyp, which ones are you considering pushing? <cbaines>unless there's a really important change that is <lilyp>yeah, i'd also postpone the recent patch for webkitgtk for the same reason. <lilyp>(hardware accel is nice to have, but not critical, plus there might be security stuff to look over) <tschilp>I could need some help regarding mcron jobs controlled via guix home. Until recently I backed up my home folder onto a plugged-in usb-disk through mcron and 'cp -pur ~/ /path/to/mounted/disk', which worked nicely. However, I decided to switch to a network-based solution. If I run the script 'run_restic.sh' (https://paste.debian.net/1311839) manually, things work nicely (files get copied to destination). But if I try to run it with <davidl__>Hi, if you want to create a system with anything non-world-readable like a private key file or whatever, whats the recommended way to do it? I would prefer to be able to use guix system vm config.scm etc. without resorting to a separate subsequent command to embed some private file in the resulting disk image. <pfna>bjc: Do I have to package them into the main guix repo, or can I just make sub-definitions in this file and go from there? <pfna>aww, no cargo importer, then? <bjc>i don't know what you mean by “main guix repo” <pfna>'upstream' back into guix the project <pfna>i presume not; no clue why i was so uncertain, lmao <pfna>i know it's not considered appropriate for guix as a whole, but is there really no way to forego the guarantees for my own personal package? <bjc>you can put them wherever you want. if you have a local guix checkout for making patches, that works. you can also do it in a channel if you want <bjc>depending on needs, a custom channel is probably the best way to get your stuff building <bjc>i do that for a few things i don't intend to upstream <pfna>i think i'll take the learning from the previous .scm I was hacking on and just build this one-off in my home directory using a guix shell to get the software goin' <pfna>It doesn't technically need rawler/rust deps as a backend, but I wanted to try it, so when I have time to try packaging again, I'll go with the older soon-to-be-deprecated c++ backend they use for raw import <pfna>Unfortunate to know that cargo and guix don't mesh well; I would have thought there was some way to cope with it by <bjc>there was an attempt to more easily integrate rust into guix with the “antioxidant-build-system”, but it stalled out a year or two ago for some reason <pfna>bjc: oh really? so someone got sick of cargo? <bjc>a /lot/ of people are sick of cargo. unfortunately not enough <pfna>i'm surprised; back in 2014 it seemed kinda nice, but so did a lot of things. did it just go the same way of pip and npm? <bjc>i guess. it is funny, though, because by 2014 the leftpad disaster had struck, but somehow no one learned the right lesson. the only thing that changed after that was making library repositories append-only <bjc>not, like, “why does half the internet rely on having these 10 lines of code” <bjc>well, /some/ people learned the right lesson. unfortunately they tend to wear black hats <wargreymon>hi all, a newbie question, how to load modules on geiser if the modules come from different channel? I searched "GUILE_LOAD_PATH" it doesnt contain the modules from other channels which I have been using. <pinoaffe>about packaging: how can I explicitly name a non-trivial input in the new input style so that I can reference it in a build phase? <janneke>pinoaffe: you mean like (list util-linux "lib")? <pinoaffe>janneke: my question is what is the modern equivalent of (native-inputs `(("test-data" ,(origin ....)))) <janneke>pinoaffe: ah, my possible answer to that question might also start with a git grep ;) <janneke>but given the complexity of this question you seem educated enough to do that yourself :) <pinoaffe>janneke: I tried a git grep, couldn't find anything apart from the "old style" though <pinoaffe>I circumvented the issue by adding a "package" containing test-data, but I don't know whether that's the idiomatic way to do so <janneke>pinoaffe: git grep -nH 'inputs.*origin' and found <janneke>base.scm:1625: (inputs (list (origin <pinoaffe>janneke: thanks, I must have been grepping the wrong things <pfna>Is there already a development environment (-D parameter) available that most people use when trying to compile stuff? Some sort of "default kitchen sink" situation <pfna>Or do things differ too much for that to make sense <bjc>oh no, is peanuts missing a botsnack command? <janneke>are you helping? please stop helping ;) <janneke>pfna: what about guix shell -D stuff? <janneke>ACTION often finds themselves writing a naive guix.scm/manifest.scm for packages that lack them <pfna>is "stuff" a specific package? <pfna>lmao, it is, but it's for astronomical cataloguing. <pfna>is that what -D causes guix shell to look in--the manifest.scm? the whole reason I was pulling this momentary shell up is to avoid packaging this rust code that will let me then package other rust code <pfna>instead, i think i'll virtualize a worse OS and hit it with the "trust me bro" <janneke>well, you coined `stuff', so i went with that <janneke>if you want to know what something like -D does, you can look at --help <janneke>it creates a shell with all development dependencies for `stuff' <pfna>Okay, what if instead of packaging all of this rust and contributing to the project, I spawn a vm in my guix script with virt-manager, build the dependency, and pull it out from there <bjc>i find it heretical, but my process with rust dev is to spawn a podman cantainer for it and then do everything in emacs with tramp <bjc>s/cantainer/container/ <podiki>you could also use guix shell --container --emulate-fhs and keep a working dir (and e.g. use rust-up in there) <pfna>i'm actually looking through the deps required and we might have almost everything needed for rawler to be built anyway <pfna>so i might have to buckle up <pfna>all of this because i was like "well, clearing out the sepples from the package will feel good" <pfna>so why can't guix's cargo build system read the cargo toml and autogen this kinda stuff itself? <pfna>yeah, just for later-me's benefit, i only gotta package enumn myself to then package rawler. the question becomes, though, how does that feed into allowing vkdt's makefile to run "cargo build" or whatever to get the artifact required? how does guix's gnu build system know about doing this instead? or do i need to modify the makefile <pfna>and add a build-rawler stage myself <bjc>podiki: there's no extant emacs infrastructure to support guix containers, though, so it's not an option for me currently <podiki>bjc: i'm not sure what you mean? like spawning and jumping in/out of containers from emacs? <bjc>also, even though docker is kind of awful, it does allow you to specify the build process in a file, which i can't do with guix (eg, the rustup step) <bjc>podiki: i mean a tramp method. with podman, everything works transparently, even eglot <podiki>adding a manifest-like file for guix shell to process as commands (as has been requested and comes up some times) would be really useful in general <podiki>and should be pretty easy, but i guess no one has tried yet :) <bjc>it seems like a weird fit for guix to me. guix is declarative, but those instructions are imperative <bjc>i will admit i have given this ~0 thought, however =) <podiki>yeah, some mix; but would be nice to have a simple "guix shell" use e.g. guix.scm to set up whatever inputs to shell and e.g. set some env. <podiki>with a container, after the first creation who knows; or if the initial steps do something like download the latest version of something, but i don't see how that is different from something like docker anyway <bjc>it's not, but also, if i wanted that docker exists already <podiki>we just don't have the easy way to provide some commands/scheme for guix shell to use <podiki>presumably we could go further using scheme, or do things in a way that would be harder from just a docker config file. but i don't have any examples, just a thought <podiki>anyway, i don't much use containers unless i have to, so i don't know much what i'm talking about :) <bjc>i used to use them all the time to isolate dev environments. they're pretty great for that. guix takes care of most of that in a better way, though, so it's only for things like rust where i still go back to them <jpoiret>moesasji: usually for service extensions you need to pass a function that takes your config object and returns the actual extension (hence the use of const for the account-service-type in your code) <jpoiret>you should be able to just use (const keyd-etc-service) instead and same for the keyd-shepherd-service <jpoiret>see how sddm-etc-service is a function that takes a config? <jpoiret>it then uses that config to generate the actual extension. In your case, you just have a bare extension, but you still need to pass a function to the service extension so you turn it into a constant function using const <jpoiret>(when you'll need values from the configuration record to generate the etc files you'll have to turn keyd-etc-service into a bona fide function) <moesasji>I need to try this; but that gives me a hint. Thanks! <jpoiret>apteryx: lrdf doesn't build anymore, for what looks like the same reason. Haven't found yet which .la file is responsible for the overlinking <h3>I try to insert a package into Guix channel to test it with `guix shell` before pushing it but all I get is that the package is unkown. How to make it known by Guix? <h3>That should update all package definitions and such, but there is two problems doing that: 1. I try to keep a fixated version of my system, so it won't update. 2. The package I'm testing right now is pushed in no channels yet, I just want to see what `guix shell` has to tell about it. If I pull, it can possibly erase my package, and if not, doing nothing more than now at making it work with the command <moesasji>If it isn't in a channel yet, maybe use the -L command line option to specify the search path? <h3>moesasji: I've used `GUIX_PACKAGE_PATH=$the_actual_path_where_all_the_other_upstream_guix_packages_are_along_with_the_new_one_I_ve_injected guix shell`. And it seems to considerate about that new package, complaining when the hash into it isn't the right format, but other than that nothing. When you correct that, it stops complaining about the new package but don't seem to acknowledge it neither <h3>Like `$the_actual_path_where_all_the_other_upstream_guix_packages_are_along_with_the_new_one_I_ve_injected/the_new_package.scm:10:12: avertissement : invalid content hash length`. But dissapear when corrected <gonzigdude>how does guix download a git repository that is gone? I guess it is related to software heritage. <gonzigdude>I need to the source code of a project hopefully from the repo to be able to restart from last commit <f1refly>I'm trying to add rust-hyprland to my system configuration but on reconfiguration guix complains about "rust-hyprland: unbound variable". I already added crates-io to use-package-modules, but it didn't seem to have any effect. Do I need to add another package module? <h3>f1refly: Don't forget to make a script/instruction to make HyprLand plug and play on Guix when you'll figure out how to make it work. And share it online <f1refly>h3: i was under the impression it would just work if I where to just launch it? <ulfvonbelow>i think the tor hidden service documentation is out of date, it says that the mappings should be an alist, but it's actually supposed to be a list of length-2 lists, at least as of the version I'm using <pret7>hello! I saw this patch on the issues page https://issues.guix.gnu.org/69973 adding the oil shell. If I use that patch for a bit and it's fine can I leave a review or something to help out with merging it? <pret7>ahh ic is in the manual cool <ghisvail>None of the earlier snapshots from Feb and Jan are downloadable either 