IRC channel logs
2025-06-07.log
back to list of logs
<PotentialUser-15>Oh my gosh I figured it out. I was modifying the package correctly, I just wasn't outputting the modified package when deleting phase, only when adding phases. <PotentialUser-15>Thank you all for your patience. I feel incredibly silly looking at it now. <getstate>Hi, I've been having issues for the past week with my system (guix describe did not show the correct channels after a pull). Turns out .config/guix/current is no longer exported within PATH <getstate>I'm using guix home to configure fish, so maybe a recent change to how bash is configured might have broke that? (since rebuilding on an older commit is fine with the same config). Can someone help? <getstate>Actually looking at it, not sure what broke? Any ideas what I can try? <getstate>All I can confirm is guix time-machine works on a certain commit (is there an easy way to do a bisect)? <getstate>Ah, did this behavior change? Do I have to export it now, just looked at the guix manual. <getstate>nvm, it should be sourced in .profile (it exports .config/guix/current/bin) <getstate>Okay, can confirm that sourcing .profile with a bash login shell works but not a fish login shell managed by home-manager <tom2342342311>I have a ssh tunnel working well with `autossh-service-type`. But how do I add another tunnel? <tom2342342311>I'm getting `guix system: error: service 'autossh' provided more than once` if I add another. <meaty>Does anyone know a quick way to test if a package's shell completions work? I've been doing it via './pre-inst-env guix package -i ...' and 'guix package --roll-back' but there must be a better way <meaty>is it ok if i close my issues on guix-patches and put send them in as PRs? A lot of them have had no response for some weeks now and I think they might get more eyes on codeberg <hako>meaty: It's OK if there's no response. ".forgejo/pull_request_template.md" can be used for a self-review btw. <meaty>hako: cool, new template, thanks! <mawumag>hi everyone. I'm trying to package a Rust crate that uses workspace and two sub-crates (https://github.com/kaizhang/SnapATAC2). `cargo build` seems to be unable to find the dependencies, enen though they are correctly unpacked in the guix-vendor subfolder (and .crate/config is configured appropriately). <mawumag>Trying to reverse engineering what is going wrong, I realized I have no idea how `cargo build` checks which packages are present in the vendor directory, as manually using cargo vendor (and changing .crate/config) works even after messing with the name of the subdirectories. <futurile>mawumag: are you using the new build-system for crates? <ruther>jackhill: what is in /etc/guix/channels.scm? <jackhill>ruther: yep, savannah is in there, and it's a link to /gnu/store/waa192z4cg1gab0zhhf9ab35ry7xxr4w-channels.scm <jackhill>suvannah does not appear in the operating system definition I passwd to `guix system reconfigure` <ruther>jackhill: so you've specified the channels with guix-service-type in your operating-system <ruther>jackhill: you must've at one point. You need to remove the file manually after you remove it from your configuration <ruther>jackhill: guix system doesn't remember what files were managed by it, so when you remove the channels field from guix-service-type, it will stay there. <mawumag>futurile I am not, I looked a little bit into it but it seems a bit difficult to navigate the docs <mawumag>if you have any tips how to learn the new system, I'd be grateful :) <ruther>mawumag: the current system doesn't really support workspaces. It is possible to build with some effort, but it is expected it won't *just* work without manual build steps / packaging the crate dependencies in the workspace <mawumag>ruther ok that is somewhat reassuring, I spent quite a lot of time on it without getting anywhere :) <ruther>mawumag: what phase does your package fai in? <mawumag>the build phase, it does not find the dependencies <mawumag>error: failed to get `anndata` as a dependency of package `snapatac2-core v2.0.1 (/tmp/guix-build-python-snapatac2-2.8.0.drv-0/snapatac2-2.8.0/snapatac2-core)` <mawumag> failed to load source for dependency `anndata` <mawumag> Unable to update registry `crates-io` <mawumag> failed to update replaced source registry `crates-io` <ruther>mawumag: please don't send multiple lines here, use a paste site <ruther>mawumag: a bot has blocked some of your messages <mawumag>sorry you are right ruther, apologies to everyone <ruther>mawumag: and do you have anndata in the cargo inputs? <mawumag>the dependencies are in `guix-vendor`, in particular `anndata` (it actually does not find any of them, I can fix by manually fixing the path in the Cargo.toml file <mawumag>yes it is there, if I add anndata = {path = "../guix-vendor/rust...."} it works <ruther>tbh I forgot how the git dependencies are supposed to work with cargo build system <mawumag>I elminated the git dependencies and the issue is still there <ruther>mawumag: did you modify the phases in any way? <mawumag>not at all, only put the relevant cargo inputs <ruther>this error is strange to me even for a workspace <mawumag>the modified builds should happen after the 'build phase <mawumag>btw, the list of dependencies is not complete, but it does not find the ones that are included <ruther>mawumag: hm. I don't really see anything strange. Can you also send the log? Not sure if I will find something there though <mawumag>but it's the usual unpacking, fixing shebang and checksums <mawumag>also, if I go to the (failed) build directory and run cargo vendor, put it on guix-vendor, cargo build works <ruther>mawumag: I just noticed... you're using source from pypi, are you sure this source contains all files from the repository? <ruther>mawumag: I would expect them to remove a lot of Rust source files for a python package... <ruther>mawumag: since you haven't included the unpack phase, I can't check <mawumag>but as I said, the build works if I download the rust dependencies manually with cargo vendor, even using the guix build environment <mawumag>it seems like cargo build is unable to "see" that the rust dependencies are in guix-vendor, that's why I was wondering if anyone knows how it looks for them <mawumag>like, how does it usually know that anyhow is in guix-vendor/rust-anyhow-x.x.x.tar.gz/ etc.? <ruther>mawumag: that is what the .cargo/config is for. It replaces crates-io with vendored-sources, and vendored sources is pointed to that directory <mawumag>ruther, but do you know how it can still find the right packages even if the subdirectory is not named just "anyhow"? <mawumag>does it read all the Cargo.toml files inside every subdirectory in guix-vendor? <ruther>mawumag: I don't know, I expected the filename is matched against the version in the lockfile <inv>i got a checkout of guix from codeberg and am trying to get an interactive dev setup, but things seem to be broken and i cant seem to find any info on the (guix config) module.. any ideas on what im doing wrong? https://paste.debian.net/hidden/c7049eb2/ <mawumag>the Cargo.lock files of many dependencies have the wrong package ! <ruther>mawumag: oh that' quite uncommon <mawumag>for example anyhow has addr2line inside Cargo.lock <mawumag>well at least I know why it doesn't build XD <mawumag>thank you so much, let me try to figure this out <mawumag>unless you already have some idea why that might be <mawumag>funnily enought, the Cargo.toml files look fine, it's only the lock files that are messed up <mawumag>and anndata doesn't even have the lock file <ruther>mawumag: not really an idea. But I just noticed they don't even have Cargo.lock committed in the repository. That's also quite uncommon for applications <mawumag>yeah many of these packages are created by people who are not primarily programmers, like me... I wonder if that might be the reason <ruther>mawumag: in that case it might help to just make a new Cargo.lock instead of relying on the one they published through pypi? <mawumag>yes I will see what I can do. Thank you so much, your help has been invaluable! <civodul>but hmm do you have commit rights for this repo? <hako>civodul: No, I don't have for that repo. <hako>civodul: I have adjusted date for the post. You can commit and deploy it if you feel ready. (I cc'd some teams, mainly for their awareness, since they'll deal with the new model soon. I think new comments can be addressed later by updating the post.) <inv>does The Perfect Setup work for anyone else? i notice i cant use any guix modules if i try to load inside a guile repl, but in a guix repl with appended load path it works fine <meaty>It seems it can't find QtWidgets/QAction... which seems to be in qtbase (I think?), which is already in the native inputs... <ruther>meaty: headers are searched from inputs, not native-inputs <meaty>ruther: thanks, but at least, naively moving qtbase to inputs doesn't change anything <ruther>meaty: there is no QtWidgets/QAction in qtbase <ruther>meaty: there is just QtGui/QAction <meaty>ruther: i was beginning to suspect that, there's a QtWidgets folder in its includes, though... times like these make me wish I could download an index for "guix locate" from the substitute server <ruther>meaty: don't suspect. Just check. Yes, there is QtWidgets, but there is no QAction under it. <meaty>yes, I just wasn't sure of my understanding of how Qt and its build systems work, maybe it did something funky <ruther>meaty: this has nothing to do with Qt, it is c++. See the g++ invocation in the log... <ruther>meaty: you seem to be building Qt 5 application with Qt 6 <attila_lendvai_>when a substitute is not available at "looking for substitutes on", then there should be a round robin algo switching to the next one, and only at the end return to the broken one <meaty>ruther: Indeed. dissecting the source, though, it seems that the missing include actually must be happening from another input--ui_MainWindow.h isn't in the primary package's source code. Looking at all the -I -flags in the g++ command, though, there doesn't seem to be any qt5 stuff... I tried building with all qt5 stuff earlier (and again just now) and it causes a bunch of syntax errors, and upstream says it should build w/ qt6 <meaty>...perhaps I just come back to this when I'm more well rested :p <ruther>meaty: there is QtWidgets/QAction in qtbase@5, bu not in qtbase@6 <meaty>ruther: but the app is a qt6 app, that somehow includes a header that refers to qt5 stuff (where that header comes from, no idea yet). <meaty>it's doom-runner, I added it a few months ago <noe>I’m wondering if there will be a way to set propagated inputs for -sys packages, would be very useful IMO <futurile>congrats hako - it's a fantastic piece of work <hako>thanks! if inputs propagation is really required, a package can be defined like before and used for replacement in rust-crates.