IRC channel logs
2024-10-04.log
back to list of logs
<omar_b>ieure: sorry I didn't think the issue was related to that. And actually this is the command I ran after cloning guix a couple of days ago and I totally forgot that I was still in that shell. :D <ieure>omar_b, Yep, no worries. It happens. <omar_b>I also didn't know about the --network flag before. I'm still learning a lot about guix. <ieure>Yeah; `guix shell -C' defaults to no networking, you need `-N' or `--network' for the container if you want networking. <elpogo>ieure: thanks for your work packaging librewolf! <ieure>Def. not a great UX that `guix shell' and `guix shell -C' have different network setups. <ieure>elpogo, Thank you for saying, it means a lot. It's been heartening to see how well-received that's been. <elpogo>did you get your commit privileges yet? <ieure>I haven't requested them. I don't think I've contributed enough, based on what's in the manual, but Ludo' said I should apply, so I will. <ieure>(Manual says 50 accepted contributions -- I'm probably less than half that) <elpogo>Well I'm just a user, but I hope you get commit privs sooner than later. <ieure>That's very kind of you to say, thank you. <[>there is if you package it <oriansj>[: to a degree (it'll solve it for me but not for anyone else); and the package definition is just a standard guix make install <podiki>never heard of "guix make install" <podiki>indeed if there is no package for it a contribution is welcome :) <jaft_r>oriansj: I expect that [ meant submitting the package to the Guix repo., once you packaged it. Then everyone would get to use it. <apteryx>hm, it's this time again. fighting with anthy to get japanese input working <apteryx>GNOME happily finds it, and I can configure it; but when I type text nothing gets converted <meaty>Would anyone be willing to help me package wallust? I have almost everything but 'vergen-git2', which seems to be looking for a zlib source package? but I'm not sure how to give it that <jaft_r>meaty: Could you also provide your package definitions you're workign with (so far)? <meaty>jaft_r: it's 168k, do you know a pastebin that can hold it <apteryx>lilyp: I think I had a reproducibility problem with GTK (4) too <jaft_r>Hey, meaty; could you put the URL for you logs, again? I had to restart my IRC client. <jaft_r>meaty: O. K. I suspect this isn't an issue, on your end, but β using the package definitions β I ran into a different error because the cargo-input rust-vergen-git2 provides a variable of rust-vergen-7 (which isn't defined). I'm going to swap that out with rust-vergen-git2-1 as I expect that's what's intended to be used. <lilyp>apteryx: flaky test or different binaries? <jaft_r>meaty: well, I ran into a different error, after, but your zlib error can be solved by just adding the "zlib" package as a regular input; should be in the (gnu packages compression) module. <jaft_r>I'm not a rust user so I'm not sure what to make of the errors but I'll put a link here, in just a sec. <meaty>jaft_r: very strange indeed, it's like it can't find itself? <meaty>perhaps I shall ask in #rust <jaft_r>meaty: it seems more like it can't find the import "palette::color_theory", maybe? But, not being familiar with Rust, I'm not sure what dependency might provide that. <jaft_r>#rust probably would know, I'd guess. <meaty>jaft_r: there *is* a package rust-palette in its dependencies, so I will check there <meaty>jaft_r: I have made some progress--the "palette" library had messed up versioning practices and added the color_theory module with a minor update, so it just needed to be updated <meaty>it's not dunce and it's not libz-sys <jaft_r>meaty: I'm certainly no expert but it almost looks like wallust is trying to build libz-sys (though I'd expect it to not choke on zlib, considering you added itβ¦); you could try adding libz-sys as a cargo-input, just to see if that changes things, but it's truly just a guess, on my part. <jaft_r>meaty: Alternatively (in case that doesn't work; I'd be curious if it does but it's just a pure guess, on my part, and could be very wrong), try adding "pkg-config" as a native-input. I noticed, starting at line 4778 of your log, that it mentioned the command ~PKG_CONFIG_ALLOW_SYSTEM_CFLAGS="1" "pkg-config" "--libs" "--cflags" "zlib"~ not working. <jaft_r>It could be that it's not properly finding the zlib you added due to pkg-config not being available. <jaft_r>I do find it weird that wallust is trying to build its own libz-sys, rather than looking for a provided dependency, but I know some projects provide their own forked versions of libraries so maybe it's just that. <meaty>either that or wallust somehow expects a copy of itself? <jaft_r>It doesn't seem so? It definitely looks like you said, coding errors with the project. But that seems unlikely, being a used package by others. Sadly, out of my depth, here. <meaty>yes, looks like a question for their gitlab perhaps <skrech>When I'm using the pre-inst-env script, should I use it from `guix shell -D guix -CWP` shell or, once Guix repo is built I can use it from my normal profile? I'm asking because I need to build a package and then install that package, and try to use it in another project. <Rutherther>skrech you shouldn't really need to run it in container even for the first build, unless you really want to ensure the environment has no play <skrech>Rutherther: So... once I build GUix I can use the pre-inst-script from my normal .guix-profile, not being in container/shell/GUIX_ENVIRONMENT? <skrech>actually, installing new package in a container doens't switch the profile currenty used... <Rutherther>skrech: you should be able to just install the package via the built guix, yes. It is expected installing new package in container won't switch your profile, as ~/.guix-profile is not the ~/.guix-profile in your real home <futurile>skrech: you can start a shell with a specific profile as well - there's a --profile switch <skrech>When I'm not in `guix shell` issuing `guix build` results in "No variable named glibc in #<interface". Isn's `guix build` command sending the build to the daemon? <futurile>skrech: If I understand correctly, you've build a package in your checked out version of Guix git. And now you want to install that into your main profile right? <futurile>skrech: if you do `guix build` in a non-shell environment, you still need the (development) packages installed in order to build. Maybe it's complaining about that. <skrech>futurile: Yes, I want to install a package that I modified in the git checkout. This is my end goal. <skrech>futurile: However, now I'm getting familiar with Guix and I'm a bit confused. So, I'm trying thigs out. So, about "guix build" I'd assume that it does whatever it does if there is no substitute available for a package. <skrech>futurile: But it seems that it doesn't do that -- it expects the developnmet requirements of Guix to be installed in the profile. <skrech>futurile: Does this mean that if there is no substitute for a package and it needs to be build from source, `guix install` will fail because of missing guix dev deps? I'd assume not, why is that? <Rutherther>skrech: it definitely should not expect the development requirements of Guix to be installed in the profile. Please share more of what you are building. And the build works fine as soon as you go into a shell, and use the same instance of "guix" executable? <skrech>Hm... seeing "No variable named glibc" I thought this is a Guix dev dep. I'm building clojure-tools <skrech>I'm getting that error if I'm not a shell and use pre-inst-env scirpt. If I run guix build without pre-inst-env and not in shell I can't what would happen, because it's already build and spits the store path (no error though). If I enter `guix shell -D guix -CPW` and use the pre-inst-env script, it again spits the store path (already built, but the first time I did it it made something) <skrech>In my head guix works something like that: saying `guix build` would send out the build request to a build daemon that would setup a container with the needed dependencies and place the result in the store. Is it like that? :) <futurile>skrech: I think you're confusing "guix package --install <clojure-tools>" and "guix build clojure-tools". When you install a package, if it doesn't have a substitute (or you tell it not to use a substitute) it will build it for you. <futurile>skrech: a plain "guix build clojure-tools" will fail in your normal env because it's a different command. Guix build doesn't "figure it out for you", it's a command for a packager so you have to set-up the right environment for it. In this case you'd be missing the development libraries needed for clojure-tools <futurile>skrech: that's why all the tutorials will say to do: guix shell --development clojure-tools ; then inside that you do guix build clojure-tools --no-substitutes <futurile>skrech: the reason you have to do guix shell --development guix, when using the guix git checkout, is that you are running the version of guix that's in that git repository. That requires you to build guix from that checkout. Consequently, you need the "development libraries" for guix itself. <futurile>skrech: if you just do a plain "guix shell" (not with --container), then that will use your default profile - and it will install the package into your default environment - so doing ./pre-inst-env guix install clojure-tools will install the one you built <skrech>Yes, thank you. I thought that guix build and guix install are doing the same thing, except the second one also install the package in the profile. It seems that guix install is doing way more than `guix build` + install. <futurile>skrech: yeah, it's basically because "as a packager" we need to have complete control, so "guix build" just builds whatever you tell it and isn't doing anything smart so we know exactly what it's doing. <futurile>skrech: as long as you use "guix shell" (without --container), you should be able to install what you built into your main profile. Commmonly I do NOT want this, because I want/need to build/install things many times: so when I'm packaging I normally use a 'guix shell --container --network --nesting --development <whatever-package-I'm-working-on> <abbe>how do I figure out why a input is sneaking into the output as a reference ? <futurile>abbe: guix graph is quite useful - reverse-bag, or references often helps me. <abbe>context: I'm working on a build-system, and the bag object that it returns has a synthetic input (an origin object) which is used during the build, and is not needed at runtime <abbe>and yet somehow it sneaks in the references, and is needed when I download the final output to a host <abbe>futurile: checking, thanks <abbe>futurile: I guess my question is what makes guix decide to put something in the references. <abbe>i have several other build-inputs, but they're not in the references, yet this one is <futurile>abbe: I find it a bit of a black art honestly. And you're working on a build-system, so not sure how you debug where it's getting things from for that as I've never worked on one. <futurile>abbe: for packages there's allowed/disallowed references which prevents it using certain packages/references. I ran into that recently. But no idea how that applies in a build situation. <abbe>find $output -type f |xargs -r -n 1 strings |fgrep /gnu/store |fgrep $undesired_reference <futurile>yeah - you might want to try and ask on guix-devel; or maybe when more people are awake in the States there will be someone <abbe>looks like it sneaked in as a embedded string as part of debug output :/ <futurile>well I guess I count as a rubber duck for that heh <abbe>ftr, i'm working on build-systems to make it easy to package go, and rust stuff <abbe>which is very annoyting at the moment :/ <futurile>yeah Rust drives me mad - I'm in the middle of 68 crates right now <abbe>i'm mostly emulating the nix (and freebsd) way, instead of one package for each origin <futurile>did you see the work for Rust that was done in the past - it never made it - I don't know why <abbe>i tried looking in the past but then i was a novice, and it went over my head <abbe>now i'm novice++ so implemented my own <futurile>nice! ah and you have env-vars easily specified <dariqq>abbe: looks cool. I am guessing that the reference is the vendor-origin object? <skrech>futurile: Just for sanuty check i did the following: In my normal shell with guix installed from the official guix intaller, entered "guix build --no-substitutes postgresql@15" and it started to build from source postgres15 + all its dependencies. <dariqq>abbe: I build your zoxide and strings on the binary has the vendor dir in there. I guess this is where the reference is coming from? For normal rust packages this is not a problem because the reference is to /tmp/guix-build-*/ and not /gnu/store ? Maybe symlinking the vendor to the build directory is enough? <abbe>that's where i messed up <dariqq>or instead of symlinking copying them <abbe>i wanted to avoid it, if i could <dariqq>abbe: symlinking seems to work for me <abbe>i wish Go could work like that too <abbe>then wouldn't have to waste I/O <dariqq>have no experience with go packages, so cant really help you with that <stochastic>is there any examples of a home-service that runs a bunch of commands a single time ? <futurile>do we use invoke in services, or system? (out of curiousity) <GuixUser>Hi, is it possible to write a service-type whose extensions depends on the service configuration? I want to write a service for liquidprompt that extends bash and zsh only if home-liquidprompt-configuration allows it. <freakingpenguin>GuixUser: I don't know of a good way to do that. You could maybe write a function that takes a config and creates an appropriate service type and service at the same time. <GuixUser>freakingpenguin: Thanks, I will try that. <ieure>tschilp, Means Savannah or a substitute server is busted. <Rutherther>tschilp: savannah git seems to be down and your reconfigure seems to trigger guix repo download <meaty>I am trying to package a rust program but I have some to certain compilation errors, I *think* they may just be "warnings" that I can skip but I am not sure, and I am not sure how I would skip them <ekaitz_>meaty: efraim did some rust packaging, but he also did too many other things <ekaitz_>meaty: he's probably busy, as he makes many things <user363627>is my understanding correct that both propagated-inputs and inputs may be available at runtime (in addition to build time)? if so, how does one get the reference to a target-specific dependency at build-time? <meaty>iirc propageted inputs only differ from inputs in that they are exposed to the end user <meaty>for your second question I would place the package in native-inputs <user363627>i have a package $foo that references a binary $bar (i'm using copy-build-system). i want to replace the binary with the appropriate target-specific reference from the store. <user363627>$bar isn't needed at build-time, but will be needed by $foo at runtime <meaty>and $bar is only used in certain targets? <ekaitz_>user363627: there are some things else we need to know <Rutherther>user363627: the "inputs" will get populated by packages that run on the target architecture <ekaitz_>user363627: the difference is how things are exposed to the user: inputs are exposed to the package, but propagated-inputs are exposed to the user <user363627>Rutherther: i see. and if a phase at build-time uses (which "$bar") it would get the appropriate reference? <Rutherther>user363627: no, because that will use the one from native-inputs, only those are in PATH during a build. Use "search-input-file" <Rutherther>the native inputs are the ones that run on build architecture, so not the ones you want <Rutherther>meaty: so are you building this on rust-team branch? or how did you obtain rustc 1.79? <meaty>Rutherther: frankly, idk. I just did crates import then made a bunch of fixes <meaty>let me put the package defs in a pastebin <meaty>mostly just updated packages and added a few dependencies that didn't get imported <Rutherther>oh, my bad. You might not need rustc 1.79, if bistream-io version is used that supports lower versions. I tried in a shell for now to see if it can build with the Cargo.lock from upstream, and didn't realize it's a problem of dependency, not of wallust itself <Rutherther>meaty: I don't know what you are reacting to. But anyway in the end it seems to be what I suspected. Something changed in rustc between 1.77 and 1.80 that makes the package not build for 1.77. So either switch to 2.10.0 instead of 3.0.0 or use rust-team branch that has a newer rustc which it builds with. <Rutherther>or if you really wanted to build 3.0.0 with 1.77, then patch of the code would be required <simendsjo>How can I make asdf systems visible to asdf? Tried `export CL_SOURCE_REGISTRY=$(guix build sbcl-dbus)/etc/common-lisp/source-registry.conf.d/`, but this doesn't work. <simendsjo>solved: I had to include sbcl in my shell and not use sbcl from my home configuration. <Guest94>Hello. guix pull hits "Git error: unexpected http status code: 502". Should I just wait till it is fixed? 