IRC channel logs
2025-08-27.log
back to list of logs
<firefly707>hello, I'm trying to write an action for a shepherd service that starts up a program and shows output, but it seems like the output for actions are masked by default? a procedure like #~(lambda (running . args) (system* "echo" "cat")) prints nothing <kratacoa>Hello, how do I unalive a profile that refers to itself? <kratacoa>I've tried running the guix-daemon as root (rather than shepherd) to no avail, guix gc -D keeps returning me the same error. <kratacoa>I want to delete it because it is unused as far as I can tell and has a modified hash error <Rutherther>sneek, later tell kratacoa: what do you meant it refers to itself? Like guix gc --referrers on X returns X? <Kabouik>Was crates-io.scm renamed to something else? <identity>Kabouik: it was sent into oblivion with the rust-team merge, see rust-*.scm <Kabouik>So I guess the replacement should be rust-apps.scm for what I was loading. Thanks, I'll try. <Kabouik>Thanks andreas-e. I'll have to read it, because so far it seems my only rust-package (which has rust-chrono-0.4 as input) is breaking guix pull because of my private channel where it is. <Kabouik>I use a private one, and this package breaks guix pull because it can no longer find rust-chrono-0.4. I tried replacing the input with rust-chrono-0.4.30 because indeed I couldn't find 0.4 in the new rust-crates.scm, but that doesn't seem to be enough. <Kabouik>I think that's because the definition still uses #:cargo-input. <untrusem>I have put a .guix-channel file so guix pulls from the git repo not the local directory <untrusem>if I remove the .guix-channel file, guix shows an error <andreas-e>untrusem: Why rain and roses? It sounds very poetic for a channel. <untrusem>andreas-e: I was listening to a song when I made the channel, this name felt cool <untrusem>actually I am thinking switch names between my system and channel <untrusem>what one have to do become member of guix, is there a document for that? <andreas-e>It depends on what you mean by "member". There are team members, for which one just needs to ask and be added by a committer; it would make sense if you could point to some work in the corresponding field. <andreas-e>And there are committers, which need to be sponsored by three existing committers. <untrusem>I see, for now I have just contributed emacs packages, but as team member are busy it takes long time to review things <untrusem>I would like info link so that I don't need to leave emacs 😆 /j <andreas-e>So maybe you could ask to become a member of the emacs team. In the end, it is more a responsibility than a perk ;-) Then you will be expected to review other people's emacs packages! <andreas-e>How come you have no browser in your emacs? Something is wrong! <andreas-e>Anyway, these are chapters in the Guix manual, which you will find somehow. <ieure>untrusem, There's been recent work on the emacs-team branch, which likely slowed review of Emacs stuff outside that scope. <ieure>I do a lot of Emacs package reviews, but have been juggling other things this summer. <untrusem>yeah there is some issue of emacs not building pkg-.el file right <Kabouik>I just don't understand the new Rust system. My package in my private channel can't seem to find the dependencies it's looking for, even though they are in `rust-crates.scm` <Kabouik>Or did you mean untrusem that I need to make the main Guix channel a dependency for my private channel? I would expect that the main Guix channel is always fetched anyway, no? <ieure>Kabouik, Your channel doesn't need an explicit dependency on the guix channel. <Kabouik>No I didn't. Checking it now, I see it uses a #:export (lookup-cargo-inputs), maybe that's what I need. <untrusem>yep, you can also look at hako and looks channel how they do it <untrusem>I was also having issue guix no finding my dependencies, i followed the template file, it was solved <Kabouik>Do you have an example to show? I checked package definitions in main Guix channel's gnu/packages/rust-apps.scm and I didn't see anything obvious missing, but admittedly I was looking at packages and not use-module. <Kabouik>Do I need my own rust-crates.scm in my private channel, or will that of Guix be used if I have none? <untrusem>your own, I think, as guix's rust-crate might not have the dependencies of your package <Kabouik>It had them, not the exact same versions but I was hoping they would work still and I would not need to make my own rust-crates <Rutherther>That is one of the main ideas behind rust-creates, to provide the exact versions, not to use similar ones. That was the case before. <untrusem>its the template file, just copy it in your channel <untrusem>and when you `guix import` it will automattically do the stuff for you <untrusem>the `(define qqqq-separator 'begin-of-crates)` are also the part of template file <Kabouik>Should I rename it to .scm myself or should I actually store the .tmpl file and wait for it to be used by guix import? <Kabouik>Okay, that's something I tried, but it didn't populate the file when I guix imported. <untrusem>hmm interesting, did you specify the file? <untrusem>guix import --insert=../rust-crates.scm crate --lockfile=Cargo.lock oniux, this was the command I used for the oniux, you also need to generate lock-file first <Kabouik>I didn't because I didn't want the importer to erase my use-module block (it generally doesn't generate that part), but I tried now with a `guix import crate tock > test.scm` and don't see rust-crates.scm changing either. <untrusem>(info "(guix-cookbook)Common Workflow for Rust Packaging") <Kabouik>I'm not familiar with this lock file thing, or with Rust in general to be honest, I just guix imported some package I wanted a year ago and it worked after minimal edits. Trying now to upgrade it with the new system. <untrusem>read the cookbook first, it will help you <andreas-e>Blog post explaining how to set up some of the technology behind the bordeaux build farm. <untrusem>do you use fedi, post it there as well with hashtag #guix :) <Kabouik>I'm confused by the cookbook untrusem. At step 2 it says to use `cargo` to generate the lock file; but I never had to even install cargo on Guix. <untrusem>guix shell rust rust:cargo cargo-audit cargo-license <untrusem>(info "(guix-cookbook)Packaging Rust Crates") <Kabouik>Okay, thanks. I admit I would never had found it; I must get that habit to always look for a cookbook. <Kabouik>So I have kabouik/packages/rust-crates.scm generated using guix import and the lockfile, it's defined with `(define-module (kabouik packages rust-crates)… )`, and I have kabouik/packages/rust-tock.scm which is the result of `guix import crate tock`, where I added teh module block `define-module (kabouik packages rust-tock)… )` and properly listed rust-crates in there, but I still get the failure to find the chrono dependency. <Kabouik>Obviously the mistake is between the screen and the chair. <Kabouik>I even pushed and guix pulled and was trying to install from git to avoid issues that could be related to me not building locally properly <Kabouik>But same build error when building locally with `guix build -L . rust-tock` indeed <Ingarrr>Does the new rust packaging module encourages reusing library definitions? <Ingarrr>I would like to use rust-indoc-0.3.6, but it's definition is totally private in (gnu packages rust-crates) and cannot be found using (cargo-inputs 'rust-indoc). <Ingarrr>Remark that it has itself dependencies on rust-indoc-impl-0.3.6 and further down. <Ingarrr>Am i expected to use the importer to recreate these library definitions? <yelninei>janneke: I just added a pr which allows customizing the image-type for hurd-vm-service. Setting it to hurd64-qcow2 will give you a functional 64bit childhurd (if you also add noide to the os kernel arguments) <Rutherther>hmmmm git is not cross-compilable due serf dependence that uses build-system not supporting cross compilation, interesting <omar_b>I am trying to sign a commit I made to be able to push it to my fork of guix but I'm getting this error <omar_b>         16 (primitive-load "/home/omar/.config/guix/current/bin/gu…") <omar_b> 2362:10 14 (run-guix-command _ . _) <omar_b>I'm trying to contribute to guix on codeberg. I forked the guix repo and I did setup my ssh keys but when I try to push to my forked repo I'm getting this error: https://pastebin.com/JrQ0FULT <omar_b>Can anyone help me understand how to fix this or share the right workflow of contributing on codeberg? <Ingarrr>Just a guess, but maybe you need to disable the pre-push authentication hook. Since you probable don't have commit access, this hook (set up by 'guix git authenticate') will try but fail to verify your unsigned commit <andreas-e>omar_b: It looks like you somehow set up mandatory signing of git commits with your gnupg key. This is set up by the project for committers who push to the main repo, but should not hold for pushing to your own fork. <Ingarrr>I moved it from .git/hooks/pre-push to .git/hooks/pre-push.disabled <andreas-e>Ingarr: I am looking at this right now, but it checks whether one pushes to the main repo, at least this is what I get from the comments. Does it not work as intended? <omar_b>Ingarrr: That fixed it thank you so much <andreas-e>Could one of you file an issue? The hook does not seem to work as intended. <Ingarrr>Ah, I see it's updated only a few months ago, I still have an old one... <andreas-e>I can already reply here: It could be one PR, but please one package update per commit. <andreas-e>Write the commit message according to our conventions, of which there are lots of examples. <andreas-e>Or easier yet for updates, use ./etc/committer.scm. If often (but not always) does a good job writing commit messages. It usually works for simple updates and package removals. <andreas-e>About the versions, I do not know. We usually prefer to package releases to random commits, but there are exceptions, for instance when projects do not make releases, or the latest release is too old to build. <andreas-e>omar_b: This is a question that only people from the lisp team can answer. <untrusem>Kabouik, ohh guix can find the packages now <untrusem>its an example, the package don't build because I am not using proper dependencies but still take a look at this <Ingarrr>Does the new rust packaging module encourages reusing library definitions?I would like to use rust-indoc-0.3.6, but it's definition is totally private in (gnu packages rust-crates) and cannot be found using (cargo-inputs 'rust-indoc). <Ingarrr>Remark that it has itself dependencies on rust-indoc-impl-0.3.6 and further down. <Ingarrr> Am i expected to use the importer to recreate these library definitions? <untrusem>omar_b, there are some hooks in .git have that might help <omar_b>Thanks andreas-e: and untrusem: I didn't know about those hooks before. The last time I contributed to guix was using the mailing list workflow. I didn't have to deal with these pre-hooks at the time <Ingarrr>not sure if you did already, but rerun 'guix git authenticate', this will update those hooks <omar_b>Ingarrr: I did run it as well and it was giving me the same error. My guess is that I originallly cloned the repo from the original guix, ran guix git authenticate and then forked the repo on codeberg and add the remote of my fork then I guess there where every thing was messed up. I might be wrong though. It's just my guess about what I did that <Kabouik>untrusem: so do I understand correctly that the significant thing there is to define rain-and-roses-cargo-inputs based on the rust-crates.scm that is in packages/rust-crates.scm in your private repo? I have tried that but that still throws the same error, I'm lost. https://0x0.st/KoVS.txt <Kabouik>Did you see anything obvious untrusem? <Deltafire>err.. how do i fix this? guix pull: error: executing SQLite query: database disk image is malformed <Deltafire>okay, fixed the db but now back to this error: guix pull: error: invalid '.guix-channel' file <Deltafire>checked the .guix-channel file in both of my channels and they are fine <ieure>Kind of wild how many FS corruption issues seem to pop up in here. <ieure>I wonder if there's something going on which is causing that or making it worse. <Deltafire>i'm using ext4 on this, so it's not just a btrfs issue <nikolar>it's also possible that your hardware just had a random error <nikolar>zfs/btrfs would've caught and reported it <vagrantc>if that were ... not such a common issue across many different people over many times ... i would say it might be a random error <Deltafire>i don't think it was that, i had 2 corrupt store items (guix and non-guix had zero byte files) <vagrantc>i see corruption a lot more commonly with btrfs than ext4 on the systems i have... <vagrantc>i run a bunch of sync calls after every system reconfigure ... which seems stupid, but here we are <Deltafire>probably should run them after guix pull also <vagrantc>at least once i had it muck up my filesystem bad enough that simply downgrading to an older version and reconfiguring did not work ... it claimed to work fine and then never actually updated anything <vagrantc>Deltafire: i don't tend to reboot after guix pull ... <vagrantc>i have only had the problem after doing reconfigure and then rebooting immediately <nikolar>guix should probably sync to be fair <nikolar>and yeah, btrfs isn't the most stable fs <Deltafire>i think what may have happened.. i some point i ran guix pull, then closed the lid on the laptop which puts it to sleep.. some time later it wakes up and goes into hibernate.. for whatever reason it struggled to resume (was getting a black screen), but eventually after a couple of tries it returned to life <Deltafire>so data was not written to disk before hibernate <vagrantc>Deltafire: yeah, that's even worse than rebooting ... basically no different than yanking the plug/battery <Deltafire>this shouldn't happen though.. even if you reboot right after reconfigure, the buffers should be flushed to disk by the OS <vagrantc>does shepherd flush the disks before calling it quits?