IRC channel logs
2023-01-06.log
back to list of logs
<pkill9>lechner: what happens when a roll-back fails? <lechner>pkill9 / no, except it seemed to throw off my (current) count to a value I did not expect. i wish i could remember the error message <lechner>it had to do with evaluating the current system generation <tremon>is it possible to do multi-line substitutions with substitute* ? <lechner>mirai / smtpd and nfs also fail with dhcp-client-service-type. more vexingly, nfs fails to set up any of the configured exports even when started manually. that part makes no sense to me <lechner>i am trying to switch away from network-manager and GDM because with them my exports became inaccessable about ten minutes after boot unless I switch to a virtual terminal <mirai>this is from a headless machine <mirai>and its using network-manager <lechner>mirai / thanks! i always needed something for the client side. my issues are on the server right now <mirai>I haven't played with guix as a NFS server mind you <lechner>this is super helpful though. i can't wait. thanks! <mirai>this is for mounting NFS volumes (as a client) <lechner>do you have something similar for smtpd? <mirai>add networking-wait-online to shepherd-requirements field <mirai>opensmtpd has gained that field recently <lechner>mirai / yay! thanks so much for sharing <lechner>mirai / why did '(networking-wait-online)' become a thing. shouldn't '(networking)' have waited instead? <mirai>the systemd units networkmanager provides do that <mirai>but guix launches networkmanager only (i.e. does not reimplement those details) <mirai>it will get fixed someday :TM: <lechner>my suggestion would be to rename the existing target to (networking-start) <mirai>though it will involve two services yes <mirai>one named start and another with -wait <mirai>mind you that it's not upstream yet <mirai>I'll take a look into it when I get the time to do so (unless someone beats me to it first) <mirai>for now I'm using those as stopgap solutions <lechner>that nfs mount is worth a lot. are you using cachefilesd? <mirai>there was a issue/patch for cachefilesd that got abandoned iirc <mirai>if that's of interest to you <lechner>yeah, i saw it. i use it manually now but hope to have that service ready soon <elevenkb>y'all's the shell escaping in `gnu/home/services.scm:L186` is really weird to me. <elevenkb>yah, it seems to take implement the rewrite rule `chr` → `chr` `\`. which is weird b.c. I'd think you'd want to escape it no... so that it is `chr` → `\` `chr` <mirai>elevenkb: I think it means that if you have a value of the form (quotes included): "foo" <elevenkb>I got that much for sure, but my query was about `quote-string` itself. <mirai>now that I think about it yeah <elevenkb>fwiw, I want to fix a _completely_ different thing which I'm pretty sure is a bug. <mirai>I was thinking that if input was foo"oo -> [o \] ["] [o] [o] <mirai>elevenkb: try playing with guix repl <elevenkb>yah, I've played with a repl for a bit. If you try to e.g. double quote the string expressed by the sign `Hello"nWorld` <elevenkb>you the one expressed by `"Hello"\nWorld"`. <elevenkb>which is a bug, there is no newline in the original string and we introduce one. the backslash should surely be before the character. <mirai>even with foldl the result would be the same no? <mirai>you will still get the quote character succeeded by a backslash <mirai>though you will invert the order of the non-quote characters <elevenkb>the more serious bug though is a change that breaks functionality that is documented in the manual. <elevenkb>basically you can't have environment variable definitions that refer to packages. <Gooberpatrol66>is it possible to run a program in an FHS container with root privileges <dtx>I've been trying to use guix shell to setup a dev environment, and it looks like the easiest most repeatable way to do this is by using a manifest. After browsing through the docs I don't see a way to automatically execute something in the environment. <dtx>And as a related note is there a way I can use guix to declaratively manage installed npm packages? <dtx>I should add to my initial statement: I am wondering on how to automatically execute something in that environment without having to specify it on the command line every time. <dtx>any help would be appreciated. <lechner>dtx / for automatic execution i think you can just append like guix shell XX YY -- your-command <lechner>or -f guix.scm or --manifest manifest.scm <dtx>is there a way to embed those commands into the manifest or something though? <dtx>I guess I could just not use a manifest and do everything from a bash shell now that I think about it. <lechner>dtx / i would create a guile script, personally <lechner>to shell out, system and system* are your friends. 'apply' may help <dtx>never really thought about using Guile for that kind of stuff. I'm kind of a n00b to that dialect of LISP, but I'll take a look. Thanks! <elevenkb>I think i might have fixed my first bug in a widely used program. <elevenkb>the fix is a small `transpose-sexp` and removing a guard but... yah. <elevenkb>i think there's another bug with this part of guix though so maybe I should just work on that. <lechner>i would prepare a patch according to the guidelines, submit a bug, and then hang out here until someone applies it <singpolyma>dtx: you can definitely manage npm packages with guix, but there is no importer so you may have to write some by hand if they are not in a channel already <apteryx>Guix has now surpassed Gentoo in terms of raw package numbers, according to Repology <festerdam>I have read somewhere about the idea of distributing packages over ipfs, which sounds like an exciting idea. What would be the main advantages doing that? The main one I can think of is the fact that one could have an almost infinite amount of packages each with different versions and compile configs without having to worry about scalability. Are there others? <vagrantc>well, they have to be stored somewhere, but not having them all stored in the exact same physical location improves some scalability aspects, yeah <vagrantc>i've often wondered how consistency is assured with ipfs, though ... <vagrantc>i mean, if you can get an object from ipfs, you're confident in the content, but ... to make sure an object is available it pretty much comes down to having to make sure it is hosted somewhere <festerdam>vagrantc: You said it would improve *some* scalabily aspects, which problems regarding scalability would still exist? <vagrantc>you still need to hold all the bits ... it then becomes a problem of tracking where all those bits are hosted <zoglesby>good day guix, I am trying to append packages to the package list in my home conf but get an error when I try the following code https://paste.lol/zach/home-if. The error is "invalid field specifier". Can anyone help? <vagrantc>if you have 16 files distributed across 16 machines, each having one copy, that but you need all 16 files ... does that really add much in terms of scalability? <zoglesby>that was not clear I am trying to use an if to check the hostname before the append <vagrantc>festerdam: i guess what i'm getting at is "just put it in ipfs" does not solve the storage problem, but you can distribute the storage across more machines easily ... but then you have to track them <vagrantc>festerdam: you might get lucky and have some of relevent stuff available by other people using ipfs at the same time, sure ... so that helps ... but you still need to make sure at least one copy is available <vagrantc>currently, ideally at least one copy of most things is available at two different build farms (although sometimes they have differences, as they both independently build everything) <vagrantc>but each build farm needs to keep a copy of everything <festerdam>Ah wait, I was very focused on the idea of distributing substitutes (every computer distributes the substitutes they built or obtained from others) and forgot that packages will often also needed to be built, the source code, derivations, etc... needing to be shared too, which needs someone to host all of them, since you can't "build" a package definition out of nothigness (contrary to a binary, which can <bjc>zoglesby: there are a number of issues with what you're trying to do. you may want something closer to this: http://ix.io/4ksg <vagrantc>also, you still need to at least get the signatures from a trusted source ... already you can add untrusted machines running guix-publish to your sources of substitutes, but it will check signatures from one of your trusted substitute servers before downloading something from the untrusted substitute server <bjc>nb: i haven't actually tried that code (it's not a complete config, so i wouldn't be able to), but the general structure should work <festerdam>Does actually GNU Guix currently have a scallability issue? <vagrantc>festerdam: it is hard to keep all the substitutes and throws away many substitutes regularly <zoglesby>bjc: to close the loop it was almost perfect, but just (map specification->package+output...) in the host-package definition not a (list...) <Luminous_Path>is there a way to find the patches listed in a package source `patches` manually? <Luminous_Path>trying to write a package and one of the dependencies has a patch that I think would fix the issue, but I'm not sure how the patches work, exactly <cnx>how do i specify the channel for a manifest? <podiki[m]1>if you mean patches taken from a packages upstream and so on...sometimes there is a comment in the patch file about where it is from (a more recent commit, Debian, etc.) <cnx>ACTION found the time machine <Luminous_Path>so the resulting derivation for an upstream input for a package should have the files in there post-application of the patch right? <Luminous_Path>it's weird because I'm trying to fix a cargo build error that, from what I can tell, should already be applied to an upstream package <lfam>Luminous_Path: Patches in Guix are pretty simple. If a package lists the package in the 'patches' field of its source, then the patch will be applied to the source code of the package before it is built <podiki[m]1>not sure I know what you are asking; if a package has an input of say pkg1, pkg1 is built according to its definition (patches and all) <podiki[m]1>if you are needing the source of pkg1, then yes also, patches are applied already <podiki[m]1>but...I don't know anything about rust/cargo and that build system, so there might be something else there <Luminous_Path>no that definitely answered my question, I wasn't sure exactly how the package patches worked <Luminous_Path>and yea as far as I know the cargo build system unpacks the input dependencies and uses the contained source for build <Luminous_Path>there's a problem with a dependency for `rust-openssl-sys` where it tries to vendor and build a different version of openssl and it looked like there was a patch for `rust-openssl-sys-0.9` that fixed it, but it looks like it's not working in my build for some reason... <lfam>I would double check that it works in rust-openssl-sys-0.9 <Luminous_Path>I thought about trying to manually rebuild it but I'm not sure how to build a package that has already been derived and hooked into my current system <Luminous_Path>it's marked in the gc tree as active (because I have a utility I'm using that requires it) <lfam>I would manually rebuild it with `guix build --check --no-grafts $packagename` <PurpleSym1>munksgaard: Just FYI: ghc-attoparsec@0.14.4 works just fine on wip-haskell. <PurpleSym1>I upgraded to Stackage 20.5 and now I have to fix missing inputs and input cycles. <PurpleSym1>Ah, dang, I misread #54729 and it’s not attoparsec itself, but packages depending on it that fail. <rekado>ACTION wants to use irregex in Guix <unmatched-paren>why do we need %store-monad anyway? imo, the only reason mlet looks nicer is because of the gexp. <unmatched-paren>if it were, for instance, (let ((drv (package->derivation bash))) (gexp->derivation store "sh" #~(...))), it wouldn't really be much different. <rekado>mlet needs the %store-monad because it needs to have access to >>= (aka bind) and return, specialized for the context that is the store monad <rekado>mlet (and all the other monadic procedures) do not return the result but instead they return an “action” <rekado>an action is a computation with a context <unmatched-paren>surely not having to write ``store'' isn't worth making a whole monads module? <rekado>the computation is executed only once a value is pushed through it <rekado>it’s not about saving on characters <rekado>these monadic procedures pass a context (the state of the store) through from one computation to the next <unmatched-paren>ah. this paragraph sort of implied to me that it was at least partially about that: <unmatched-paren>> There are several things to note in the second version: the store parameter is now implicit and is “threaded” in the calls to the package->derivation and gexp->derivation monadic procedures, and the monadic value returned by package->derivation is bound using mlet instead of plain let. <rekado>the store monad is a variant of the state monad <rekado>using a monadic style lets you write code with “effects” in a purely functional way <rekado>a non-monad example would be a purely functional pseudorandom number generator that returns its seed alongside the random value <rekado>you need to pass a seed to the generator to get a new pseudorandom value out of it <rekado>when calling it again you’ll have to pass it a new seed, the one you got back last time <rekado>in the state monad this seed value would automatically be passed from action to action <rekado>the monad machinery takes care of that; all it needs is a definition for >>= (bind) and return <rekado>unmatched-paren: bind is a function that takes two values: a monadic value and a function from a non-monadic value to a monadic value <rekado>in Haskell type notation that would look like this (>>=) :: M a -> (a -> M b) -> M b <rekado>where “M a” is type a within monadic context M <rekado>this whole monad business is really just a way to benefit from a useful pattern of combining stateful operations with predictable order and without having to do all the plumbing by ourselves <zimoun>rekado: the Guix store monad is a state monad. A Store is a comonad. Well, maybe category typists around could correct me. <paul_j>zimoun: Thanks for this article and link! I have tripped over at the first hurdle :( - when calling guix repl, if I put something in like (+ 1 2), then I get a "Fatal error: glibc detected an invalid stdio handle". I get the same result when calling guile from the terminal. Have you (or anyone else here) seen this before? I am not sure how to trouble shoot this! <zimoun>paul_j: never seen this error. Some of your environment variables are probably messed up. <paul_j>Thanks- I'll have a dig and see if I can find something. <rekado>paul_j: is this on a foreign distro? <paul_j>I don't set any in my configuration which should cause this, so I am a bit confused... <rekado>can you reproduce this with just “guile”? <paul_j>Yes - exactly the same error message <rekado>it probably wants to load readline <rekado>I wonder if there’s an outdated/incompatible readline library somewhere <rekado>paul_j: do you have guile-readline installed? <paul_j>Not explicitly from my configuration for system or home. How do I see if it is installed as an input? <rekado>another thing to try: guix shell --pure guile guile-readline -- guile <rekado>does “guix shell --check” give you any warnings about environment variables? <paul_j>"guix shell: All is good! The shell gets correct environment variables." <paul_j>guile still generates the same error in that environment as well <rekado>and from your home directory: guix shell -C guile guile-readline -- guile <rekado>(from home dir so that ~/.guile is available) <gabber>i'm hacking my way through Guix' container/shell generation and activation. i've successfully added an additional group to /etc/group and even added the right uid to the entry. weirdly(?) enough the group does not show up when i type `id` or `groups` in the container shell.. this puzzles me somewhat: does anyone here have ideas on what to check/how to hack the issue? <rekado>gabber: you cannot do this when launching a container with limited permissions <gabber>WDYM "with limited permissions"? <rekado>are these groups/user ids to be mapped from the host? <gabber>no, they are to be created within the container (this step succeeds) <gabber>and diving in i'm thinking stuff like: why not add a --supplementary-groups option to the --container? or even an --expose-audio? <gabber>rekado: i'm not sure.. for the subuids are not to be found on my host (guix) system. i always thought "adding" a user to a new group was to add/adjust the right entry in /etc/group and login again. but thanks for your input, i guess i'll continue diving into the source tree :) <oriansj>nckx: thank you for helping me realize that: guix package -A | awk '{print $1 "@" $2}' | xargs guix build --no-substitutes would work <nckx>You're… welcome, but I'm confused. It should always have worked? <nckx>Did you hit some edge case? <oriansj>nckx: I kept thinking it needed an option like -f or -e or something <nckx>Ah, no. It takes name[@version]s and (drv) file names by default. <oriansj>the --help might wish to clarify on that point <nckx>I think PACKAGE-OR-DERIVATION is clear enough. <oriansj>fair enough, guess I misinterpreted it <nckx>I haven't tried -e with multiple return values (so you could directly -e fold-packages without needing a separate query & pipe at all). My guess is it won't work. That might make a nice addition. <oriansj>but atleast I have a possible route to setting up my own offline guix substitutes server <oriansj>a download server to run the above command and download all of the tarballs and patches needed; Then I can burn those to DVDs and import them onto the offline build server <nckx>Interesting. I wonder if it will work first try. <oriansj>well it would be much easier IFF guix would just put all the source code and patches into /gnu/sources/ <unmatched-paren>it will download and verify them from the original source if the sources aren't available on ci <oriansj>unmatched-paren: I need the source code for anything I am running <unmatched-paren>which is then compiled to a derivation that builds a source store item by downloading it and then checking the sha256 specified <elevenkb>is there a standard choice for plain text markup that is used in the guix mailing lists, or perhaps the gnu project in general? <nckx>Having a more explicit notion of ‘this is Source, it was written by Humans and should contain no Generated Files, amen’ in Guix is an interesting idea. It's currently more ambiguous (most source origins are, well, source; but not all; most inputs are generated [by us]; but not all). But that does not need to extend to the file system level and /gnu/source. <nckx>elevenkb: Hmm, interesting, no. There's ‘conventional historical e-mail mark-up’ like _this_ and *that* (no, that's not ‘Markdown’, you hipsters) and I've even seen some Org, but there's no standard and anyone who says so is dreaming. <unmatched-paren>elevenkb: the readme is org mode, the manuals are texinfo, the blog posts are markdown, and the other web pages are mainly sxml :) <nckx>Oh, I thought it was purely about mails themselves. <nckx>Patches, yes, we prefer them to be marked up using ‘diff’ and ‘Scheme’ thank you very much. <unmatched-paren>oh, right, i misinterpreted "or perhaps the gnu project in general" i think <rekado>ACTION feels the strong urge to clean up (gnu packages java) <elevenkb>i _also_ felt like pointing at that resource :p <elevenkb>but i thought it'd be helpful to get more specific information about telmo[m]'s background <graywolf>I feel like an idiot. I've spent quite some time trying to boot up guix in a vm (based on my own operating-system definition). (source) in lvm-device-mapping should be the volume name, not the physical device the volume is on. Fair enough, it is documented, I just cannot read apparently. However that seems to imply that *order* in mapped-devices does matter (since there is no link between the <telmo[m]><elevenkb> "telmo: for what purpose?" <- web programming and programs programming <graywolf>unlocked luks and the lvm inside it)? Is that correct? <mirai>I think activation-service-type is a big big mistake <mirai>if used strictly for running things at boot-time I agree <mirai>then that means using it for file-system related actions will happen regardless of the actual physical storage device <mirai>you can create files that will get shadowed by mounts <mirai>you can't have services use non-vanilla mounting points <bjc>ideally, a lot (all?) of activations should be moved to shepherd one-shots <bjc>we still need better tools for manipulating shepherd's dag, but it'd be a start <mirai>and even if you were to make a service "depend" on networking or another service that creates a directory it either happily create files where you least expect <mirai>there's a non-trivial potential for data loss as well <mirai>depending on what the service uses the activation for and where it is located <mirai>it completely subverts the meaning of "service requirement" <mirai>it will result in a lot of shepherd noise though, unless it can be hidden <mirai>it = these "special" one shot services <civodul>yeah i think activations that merely create files/directories before a service is started should be moved either to new one-shot services or to the corresponding service's 'start' method <bjc>hrm. i think i misremembered how activations work and thought they were run on boot, but they're actually run during reconfigure <bjc>so they're not necessarily convertable <civodul>so there are other types of activations that should probably not be changed <mirai>running at reconfigure makes this "issue" even more confusing <bjc>it means they'll have to be gone through to see when its appropriate to ron them <mirai>because by that point, things such as mounts, other services, etc. that create the expected directories already happened <bjc>creating a user or group, for instance, should stay at reconfigure, not boot <mirai>and the reconfigure will work <mirai>reboot and you'll be greeted with either missing data or failed services <bjc>iirc, the existing file-system stuff from the os definition already is a shepherd one-shot <mirai>by "issue" I mean using activation to create files/directories <mirai>and other actions that actually may depend on other services <bjc>yeah, that stuff would need to be converted to shepherd one-shots, as they're discovered <bjc>i don't think there's anything standing in the way of doing that now, but i haven't tried, either <mirai>one way is shepherd one shots though unless you can hide these entries or stuff them into another shepherd instance to group them up it will result in a big mess at 'herd status' <mirai>other way could be moving them (?) into start procedure <mirai>^didn't think this one too carefully <mirai>might be messy as it could involve "state tracking" <bjc>to me, that means that ‘herd status’ needs the ability to filter, or some equivalent. it's the same issue systemd has, which i don't find troublesome in actual use <mirai>systemd usually gives you structured output <mirai>herd will give you line-by-line output <bjc>systemd can be coerced into doing both, depending on how you ask it <mirai>unless you start prefixing things which will be "by convention" <bjc>from my point of view, it's more valuable to me to be able to have a singular query interface which may contain many things, than to have to query multiple things <bjc>the issue being that for system services, they already all exist in a global graph by nature, and i want to be able to see that global status <civodul>we can change the 'herd' UI if needed <civodul>we should prolly do that anyway, to have something that resembles 'systemctl status' <bjc>yeah. i'm not a huge fan of systemd, but systemctl status is pretty nice to use <mirai>but how should we restructure these service one-shots? <bjc>i don't know without looking at them. i suspect it's going to vary per-case <drakonis>enhanced herd cli is very high on my feature wishlist <bjc>one problem that jumps out is that if something depends on a file-system being available, there's not going to be an automatic way to check that <drakonis>so much that last time i tried to get someone to use guix, the first thing they complained about is herd's UX <drakonis>also support channels for other languages, as we've been getting people with slightly less than ideal english skills <bjc>i think there's a post-mount shepherd provision you can use, but i can't remember it off the top of my head <bjc>but that requires all your file-systems to be listed in your os config, which is only a problem for something like zfs without native support, or maybe things that use fuse or bind mounts <bjc>drakonis: what do you mean by “channels for other languages”? shouldn't localization files be installed in a channel-independent manner? <bjc>i think my brain glossed over that word for some reason. sorry about that <festerdam>I'm on debian, but when I do guix pull, it freezes right after saying Building from these channels: [list of channels]. What is it doing at that moment? <graywolf>Is there a nice way to share content between multiple system definition files (`(operating-system ...)`? <graywolf>unmatched-paren: I guess what I'm unsure about is how to distribute it. I currently have a module added to path using (add-to-load-path). That works during system init, however on reconfigure time (current-file) returns #f, so that blows up. I guess I want to 1. have all files in one git repo 2. share some code between the system definitions 3. have it work both for system init and system reconfigure <graywolf>So I'm not sure how to tie it all together <bjc>part of the problem is going to be managing provenance. currenty, guix only saves your config file <bjc>i think the best way to do what you want is to create a channel, then use definitions from that <bjc>guix will at least be able to hanlde provenance that way (though you will need a way to keep the new channel valid across time, if that's something that matters to you), and it'll handle load-path issues <bjc>if there's a better way, i'd love to hear it. adding a channel for this seems clumsy to me, and it's been what prevents me from modularizing my own config in a way i'd like <graywolf>unmatched-paren: Two questions: 1. how do you actually load since (current-file) returns #f, so how do you determine the correct directory? <graywolf>2. load vs primitive-load, why prefer the latter one? <bjc>you can't recreate your previous system that way, though, right? will ‘primitive-load’ also pull the file you're loading into the store? <bjc>right, that's my main issue <bjc>it'd be nice to have better support for modularized configs without a channel <balduin>Hello, I have a Purism laptop running Guix SD. However, I have some problems with kernels > 5.15. Is there a way to stay on the 5.15 kernel, while still upgrading the rest of the system? And how would I do this? <graywolf>The channel way as described above sounds... "fun", so I would like to avoid that. <graywolf>Maybe just templating/copy-pasting the shared data into multiple files is the answer for now? <nckx>balduin: (operating-system … (kernel linux-libre-lts) …) ;; is currently 5.15 <nckx>Don't forget to import (gnu packages linux), but Guix will probably tell you that. <nckx>unmatched-paren: No, -5.15 is more explicit and will break instead of silently upgrading you to the next LTS when the time comes, so is better in that way. <nckx>One would hope that whatever regressions will be fixed by then! <bjc>graywolf: channels aren't that hard to set up. i think they seem more intimidating than they actually are. but i agree it's not the best <graywolf>bjc: Well I want this to be private data, so I would need to distribute private key to do the git pull with the installation media, seems like a hassle <bjc>you don't strictly need a key. i operate channels without them, but they're only for my use <graywolf>oh, how do you do access control without a key? <bjc>the key is for verification, not access control <graywolf>or is this only-for-my-use-but-technically-open-to-the-public? <bjc>the channel itself is just a git repo with some metadata <graywolf>Ah right, I want to be able to actually restrict RO permissions <bjc>you manage permissions by managing the git repo <bjc>or maybe i'm misunderstanding what you're going for <graywolf>If this would be a channel, I want the git repo (where the channel would be) to be private repository requiring credentials to git pull <graywolf>Which would mean I would have to distribute credentials with the install usb disk <bjc>ah, ok. yeah, i don't think there's a solution for that <graywolf>For the time being I will just copy&paste the section of the configuration into multiple file and postpone proper solution for later <nckx>graywolf: But you'd be fine distributing these files themselves on the installation medium? I don't quite follow. <festerdam>Ok, also guix install freezes. I'm stuck at «The following package will be installed: hello 2.12.1» Am I supposed to do something to get guix working on debian? <nckx>graywolf: As in, I don't understand how channels add any hurdle here. Surely not using channels has the same problem. <graywolf>nckx: Yeah because it is for my use on my machine(s), I just do not want this to be publicly on the internet, that's it <nckx>Why can't you pull from a local git repository? <mirai>just include them into your config.scm <nckx>ACTION gets the spray bottle. <nckx>festerdam: For how long? <graywolf>Anyway, if I got "Hardware support warning" in the installer, are there ways around that or am I just out of luck as far as GuixSD goes on this laptop? (alpine runs fine) <drakonis>none of them are any particularly difficult to find though <unmatched-paren>graywolf: you can use a file://... spec in your channels.scm to point to a local git repo <festerdam>nckx: Still stuck since I wrote that message. How long is it supposed to stay like that? <nckx>Not. I just wanted to know the kind of delay you were talking about. <nckx>If you run the same command with --no-substitutes, does it at least start doing stuff rather immediately? <nckx>OK, so the ‘freezing’ Guix is waiting for substitute info… <festerdam>Guix pull also works now. Maybe I somehow messed up my substitute list some time ago? Going to check that. <nckx>Or one of the servers is having a little episode. <festerdam>I remember it being like that yesterday, so I think it's on my side. <festerdam>Ok, it also doesn't get stuck with --substitute-urls. <festerdam>(with the --no-substitutes option removed obviously) <nckx>Well, the default is to query both of the URLs I quote above, so I'd expect *one* of the explicit --substitute-urls= to hang in the same way. <nckx>If --sub-urls=A and --sub-urls=B work, I don't know what went wrong. There's no third one. <bdju>any 3d printer users around? I see we have prusa-slicer and cura packaged. I heard superslicer was good so I was thinking of using that. maybe I'll do the slicing on another machine for now <bjc>you could try your hand at making a superslicer package ;) <bdju>I have been a guix user for a few years now and I still don't find packaging very approachable. at most I'll usually add to the guix wishlist on libreplanet <graywolf>If I add some new channel, can I restrict what software can be installed from it? So that I do not use it, even by accident? <bjc>not that i know of; if a channel has a package, then users of the channel can install it, and if it shadows a guix package, it'll be preferred over it <graywolf>Can I at least prefent the shadowing and prefer guix package (if available)? <bjc>i'm not sure, but i doubt it <festerdam>Is there a way to only allow substitutes when pulling? I'd rather avoid having to build the whole linux kernel + all the other stuff. <bdju>people have been asking for that feature for ages. I don't think it's possible yet. best you can do is check with guix weather or --dry-run if it's going to build something, and then wait to upgrade until later if something big needs to build <bdju>that and do a partial upgrade skipping anything that needs to build in the meantime <bdju>(manually, by listing certain packages) <festerdam>bdju: What is currently preventing that feature from being implemented? <balduin>I have another question, I get this warning: /etc/config.scm:34:14: warning: the 'target' field is deprecated, please use 'targets' instead -> however, how should `targets` look like? Currently, it looks like this: (target "/dev/sdb"). <bdju>I think there was discussion ion the mailing list about it in the past but I'm having trouble finding it <bdju>yeah, that seems relevant. I also recall a thread discussing why a guix pull did so much stuff <bdju>fyi, I'm not a maintainer or anything, just a user and someone subscribed to the mailing list, so maybe someone else could better explain <nckx>channels-with-substitutes-available handles the ‘guix pull’ side: it should pull the latest revision for which the result of ‘guix pull’ can be substituted. As for packages, nobody has written that feature yet, which is why it's not available. <festerdam>nckx: Huh. Shouldn't the default channels have substitutes? <nckx>CI sees master as soon as you do. <nckx>There is no branch that trails behind master that gets updated when things are built, or somesuch. <festerdam>nckx: Sorry, I'm still very inexperience with guix. So that means the default-channels don't have any substitutes? <nckx>It is not a binary thing. <nckx>Guix master will have the majority of substitutes available at almost any time, but possibly not the most recent changes, as CI will still be building them. <nckx>If I update icecat on master, CI will notice and start building it within minutes. If you immediately guix pull && guix upgrade icecat, you won't get a substitute, and will also start building it. But if you wait a few hours, chances are you'll get a substitute. <nckx>There is no mechanism yet for the CI to signal to users ‘OK, I've built the new things’. <nckx>At least not one that's integrated into Guix. <apteryx>rekado: I'll push the u-boot changes soon, unless you had something more to add (thanks for the review!) <lechner>the parentheses used to work but i made some changes yesterday. I'll have a look <lechner>Hi, may I please retitle #57589 to read "hangs"? <civodul>lechner: sounds like a reasonable change :-) <festerdam>Why does it take so much time to compute derivations? Isn't a derivation just a file saying the dependencies for building a package, where in the store the output should be stored, and how it should be built? My guix pull seems to be stuck at «Computing Guix derivation for 'x86_64-linux'» for the past 10 minutes now. <lechner>i also had that issue yesterday, but i just waited <jpoiret>festerdam: guix builds a derivation that will build all of guix, for that it needs to compute the list of modules that will need to be compiled and properly order some of them, this is iirc what takes a while <jpoiret>at that stage, guix computes a bunch of different derivations <panosalevro>is there any room for improvement for speeding up this process? <festerdam>jpoiret: Shouldn't it be something CPU intensive though? Because htop shows almost no CPU activity. <jpoiret>no, it's mostly IO intensive since you need to read a bunch of files and parse them (or at least the #:use-module parts) <vagrantc>apteryx: huh. i definitely tested u-boot on the wandboard ages ago ... surprised it was missing anything. imx6 hasn't changed much... <rekado>apteryx: sorry, haven’t been able to make time for another round of reviews <rekado>I think it looked pretty okay; if my previous comments were addressed I won’t object to merging it. <festerdam>Is there a way to make guix more verbose? Because there are often times where I wonder if Guix is doing anything at all and I'm unsure if a problem occured or if it simply needs more time. <vagrantc>apteryx: oh, i see some definite problems with the u-boot series ... will comment <oriansj>unmatched-paren: the idea was to make it easier for people to setup offline mirrors of the source code for packages that have guix knows how to build. (thus ensuring the source code is always available locally) <vagrantc>apteryx: the summary comes down to repurposing make-u-boot-sunxi64-package to be repurposed for rockchip rk3399, which will break all the existing sunxi64 packages that use it. <apteryx>rekado: OK, no problem, thanks for your reply here! <apteryx>I'll have a look to what vagrantc has to say :-) <vagrantc>apteryx: i don't have much comment on the rest, but that one thing leapt out at me as quite wrong <vagrantc>apteryx: with be rewrites like this it seems important to actually test on affected platforms, as things can build fine but actually fail to boot the systems <vagrantc>ACTION is in the middle of testing major u-boot updates in Debian, and was planning on then proceeding to update u-boot in guix once 2022.01 comes out maybe january 9th <festerdam>jpoiret: Htop also doesn't show any particular process that's constatly doing reads and writes, though. <vagrantc>though now maybe i am thinking to test it woth 2023.01-rc4 ... so that a patch is nearly ready to merge when it actually releases <lechner>rekado / the 'bos' just mirrored what we had before. it prevents confusion with line numbers in URLs. (the link you send had one, for example.) i am not sure we care enough about parenthetical expressions like the one apteryx used, since IRC not really a prose medium, and bugs are usually front and center <vagrantc>there were issues discovered in u-boot 2022.07 that I'm just now sorting out in Debian, and didn't want to inflict those on guix <vagrantc>although i was tempted to convert one platform at a time with a u-boot-202x.mm for newer versions ... would certainly be a safer transition, at the cost of maintaining more upstream versions <vagrantc>but maybe best to just move it to 2023.01-rc4 <vagrantc>moving all of u-boot all at once is, in my experience, highly likely to break at least one board <vagrantc>luckily, guix doesn't support all 1200+ platforms :) <apteryx>that's an upstream problem though, and I don't think it's reasonable to expect any of use to test even the limited set of boards that we support <vagrantc>i don't think it is great to break booting on people using guix either <vagrantc>and honestly, there are a number of u-boot builds that are probably extraneous ... e.g. u-boot-malta is basically unobtainium (although i think qemu supports it ... maybe) <vagrantc>i know there was a mips port for guix at some point ... but not sure that is going to have a comeback <vagrantc>although calling it an upstream problem, i don't understand ... i don't think guix takes upstream no matter the problems it introduces ... ? <vagrantc>i mean, definitely, encourage things to get fixed upstream ... also make sure things work in guix, no? <lilyp>if an earlier version worked for you, you can roll back/time-machine/whatever <apteryx>it failed a test; the build passes here <mekeor[m]>mekeor: i mean, it's sad enough that not everyone has the chance to go to brussels, e.g. from other continents, e.g. because of financial or legal reasons <rekado>lilyp: why not fix it in Guix then? <apteryx>vagrantc: yes! I think it's best effort thing. Nobody expects one individual to have 50 ARM devices to test all the subtle variants of U-Boot builds. When it breaks, we fix it. <vagrantc>apteryx: fair. i had reasonably good success putting a call out for testing u-boot recently in debian ... might be worth doing just so someone doesn't end up with a surprised borked system (e.g. testing it they know to look for surprises) <nckx>Sounds like a team (in addition to a public CfT). <vagrantc>yeah, i recently submitted a patch regarding adding myself to the embedded team too <apteryx>embedded teams seems to be just about embedded *bootstrap* <apteryx>or it's just waiting to get files added to its scope? <apteryx>such as gnu/packages/bootloaders.scm <vagrantc>yeah, there's a patch sent to guix-patches about that ... and a thread on guix-devel touching on it <vagrantc>it has no description, so ... *shrug* who knows what it is about as a team :) <lilyp>mekeor[m]: I seem to have missed the cfp :( <vivien>Dear guix, gnulib has a feature to make programs and libraries relocatable by default. If you pass "--enable-relocatable" as a configure argument, and if the package uses the relocatable gnulib module, you can get a program that is relocatable by default. It is not advised to do this for setuid programs, but should guix try and enable it every time it can? That may give relocatable packages for free. https://www.gnu.org/software/gnulib <vivien>/manual/html_node/Supporting-Relocation.html <attila_lendvai>i'm trying to apply a patch series from debbugs in emacs (eris, 52555, 8 patches), and it's annoyingly hard... i ended up wget'ing the files from issues.guix.gnu.org and `git am` them one by one. <acrow>While doing the git pull; guix shell -D guix guix --pure; ./bootstrap dance for testing, during make I get the error paste.debian.net/1266352, can anyone tell me what I missed? <lilyp>attila_lendvai: does the patch-series link not work? <bumble[m]>hey everyone I installed guixsd on a laptop and basically do not know anything about guix. If I want to install, for example, "git" or "irssi" should those be added to an scm configuration file, or should those be installed with "guix install"? would someone recommend the best way to start? <apteryx>lechner: there's no problem with u-boot per see; it's software, bug happens :-) I don't know about wolfBoot <attila_lendvai>lilyp, i was hoping that there's a workflow in emacs that most devs use, but i couldn't find any emacs commands to apply a git commit (c.f. not a simple patch that i then need to commit by hand), but i couldn't find it. not sure what you're asking, but i could download the patches one by one, and git am them, but this is a rather unsatisfying workflow in 2023. <acrow>bumble: guix install is a good place to start. I use "guix package -i git" <apteryx>M-x cd $guix-git-checkout; put cursor on email; | -> git am -3s RET <attila_lendvai>apteryx, i was using M-x debbugs-gnu-guix-search, and messing around in its output <apteryx>you have to set the current directory for the parent Gnus group so that it sticks <apteryx>you can apply multiple subsquent email with the prefix argument (e.g., C-u 5 |) <attila_lendvai>apteryx, it sounds better, thanks! i must note though, that it's a very steep learning curve, even for a seasoned emacs user who never learned gnus... <acrow>bumble: np. I hope you like what you find. <bl0rt_tmp>I'm following a tutorial to get guix running as a digital ocean image, and was getting a problem with the certificate when running 'guix pull' so I ran 'guix pull --url=http://git.savannah.gnu.org/git/guix.git' and ame now getting an erro r 'some substitutes for the outputs of derivation ... failed'. I'm new to guix so not sure how to troubleshoot <vagrantc>lechner: wolfboot looks interesting, but very few supported platforms <lilyp>Gooberpatrol66: IIRC, `guix pull --news --list-generations' should work, but that won't show you any news older than the second generation, obviously <festerdam>jpoiret: I'm pretty sure guix pull isn't doing anything. It's been stuck computing guix derivation for the linux kernel for 3 and a half hours now with no cpu or disk activity. Is there any way to make guix be more verbose in what it's currently doing? <vivien>For circular dependency resolution, I would like to extract a package from a module and put it into its own. What should I keep in the copyright header? <lechner>apteryx / your parenthesized calls to the bot earlier today are not covered by any current regular expressions. i too had not noticed those uses here in the channel. please let me know if the bot should be modified to cover your particular use cases <zacchae[m]>How worried should I be if "make check" fails on a local build of the guix repository? <rekado>optionally append /<n> for the nth iteration <apteryx>lechner: (#xxxx) seems like it'd be useful <nckx>Oh, does (#666) not work? <zacchae[m]>Specifically I get TOTAL: 2293, PASS: 2230, SKIP: 57, XFAIL: 4, FAIL: 2 XPASS: 0. I did a fresh pull, bootstrap, configure, make <nckx>vivien: All people who meaningfully contributed to the moved code. Depending on what remains in the old module, remove their name, or keep it. <vivien>Can I just duplicate the list? ^.^” <apteryx>the hipprocratic license is not free software right? <apteryx>hmm. Debian continues to license ruby-vcr as expat; isn't this wrong? <vivien>Okay, so I’ll try and parse the git log then! <apteryx>which guideline of the FSDG does the hippocratic license goes against? <apteryx>I thought the FSDG said something about "for any purpose", but that seems to be the GPL, rather <apteryx>hmm, probably more simply about that it's about free software, and hippocratic not being considered a free license, it's barred <vivien>nckx, I’m careful to check for each year, but sometimes an author according to git did not claim copyright on the file. Should I forcefully add them, or should I not? <nckx>Nah, stick with what they claim. I don't want to make it even harder on you than is necessary. <lechner>yeah, it may also compromise the credibility of the entire record <vivien>Oh, I’ve realized that I had to go through each commit and re-do the copyright assignment for both files anyway because of the dates. <vivien>So that’s not more work to add them. <vivien>There are lots of problems, but checking authors and copyright dates based on a git log is an easy one to solve :) <vivien>The author of merge commits between master and core-updates shall not get a copyright notice <GYBE>Hej! I already asked in #scheme, but maybe somebody here knows. How do you get this rainbow-delimiters like colors in the parentheses on guix manual's website? <sneek>GYBE, nckx says: I do get & read your messages, but you're never on-line when I reply :) <gnucode>GYBE: there might be a guix blog post that briefly talks about how they set that up. <rekado>GYBE: it’s all in doc/build.scm (in the Guix source tree) <rekado>GYBE: syntax-highlighted-html is what you want <rekado>it processes the output of guile-syntax-highlight <GYBE>I am working on SICP now, and I wanted to do a static website with Haunt, but it would be cool if I can have such a fancy feature in my listings :)) <GYBE>I will try to see how to borrow ideas from that guix module <vivien>I fear the day we will have to split large modules such as python-xyz <nckx>sneek: botsnack you silly bot. <dthompson>speaking of guile-syntax-highlight, I just updated that to 0.2.0 <civodul>dthompson: oh nice! any incompatibilities or things to be aware of? <rekado>ACTION moves the java bootstrap stuff from java.scm to java-bootstrap.scm <dthompson>civodul: thanks for mentioning the signature issue. I don't hack on this project much and it still had a broken command in the makefile for signature generation. <dthompson>hey while you're here: what are the implications for updating guile-fibers? there are several package variables so I was thinking of making a guile-fibers-1.2 variable to contain the latest release. <dthompson>would be nice to use that version for guile-goblins development. <civodul>ACTION tries "guix build -S guile-syntax-highlight --with-latest=guile-syntax-highlight" <civodul>ah looks like it's already in a future commit of Guix actually :-) <dthompson>oh does that look for signatures? didn't realize that! <dthompson>I've been using it for my own website for quite some time <civodul>i noticed because "guix build guile-syntax-highlight --with-latest=guile-syntax-highlight" found substitutes <Aurora_v_kosmose>I asked in the #guile channel proper but I figure you folks might also know... where are Guile docstrings documented at all? I know there's some fancy variable formatting & interpolation somewhere but I don't know where to find the reference. <oriansj>Aurora_v_kosmose: do you mean the formatting rules of the docstrings or the docstrings baked into guile itself? <vivien>The docstrings are in fact texinfo <vivien>You can use @var{arg} in the docstring if arg is an argument of the function I think <oriansj>I believe those are "blocks" inside the source code itself <bl0rt_tmp>Just following up on my message from earlier, I ran 'guix pull --url=http://git.savannah.gnu.org/git/guix.git --fallback' which seems like it's caused me to have to build a bunch of packages from source (it's been building for 2.5 hours now. I've been checking back on it, and it has been making progress, but this digitalocean droplet doesn't have <bl0rt_tmp>that many resources). I'm still not really sure why I had to specify the URL and fallback variable to make it work, but am wondering whether doing so is the reason the build is taking so long and how I ended up with mismatched keys on the first pull <bl0rt_tmp>the steps I was following had me run the command 'guix archive --authorize < ~root/.config/guix/current/share/guix/ci.guix.gnu.org.pub' at one point after downloading the source of the version being used by the article I was reading <bl0rt_tmp>Does anyone have any generic advice for avoiding this kind of issue? Keyring / package repository issues are a recurring pain point for me across a few different technologies and I'm not sure exactly what I'm not getting. I think I had a similar problem the first time I tried to run the guix package manager on my computer <gnucode>bl0rt_tmp: I think you need to run sudo guix pull at least once... <gnucode>I have 2 linode servers and each have 1 GB of ram. <gnucode>they both run guix system, and work quite well. <bl0rt_tmp>gnucode: interesting, does linode have a guix image available? On this DO droplet I have not set up users (except the guixbuilder users) so everything is run as root rn <gnucode>bl0rt_tmp: You can actually use the guix cookbook. It'll walk you through setting up a linode server. <bl0rt_tmp>gnucode wow that's awesome, I guess it's time to finally setup a linode account lol <gnucode>I just used that guide last night to install my second linode server. I realized that the guide skips over a few things, but overall it works really well. <gnucode>The gotchas that got me last night included: I needed to run "up-get update" before I could install gpg. 