IRC channel logs
2026-02-13.log
back to list of logs
<loquatdev>I'm writing a service that is essentially a wrapper over another service. This service that I'm wrapping does not allow other services to extend it. I included it as a service extension anyway. I received no errors, but the actual service doesn't do or create anything when I actually reconfigure the system. What's the appropriate way to write a service that sets up and manages another service that can't <loquatdev>be extended? Or, am I understanding this completely wrong? <loquatdev>I'm creating a thin wrapper around greetd-service-type that can be composed/extended, where the "configuration" is a list of greetd-terminal-configurations <mange>You can't extend a service unless it declares an extension point. The right think to do is to add the extension that you need to the target service. <mange>I'm a bit surprised you didn't get an error, though. <loquatdev>Maybe it's because my default value is an empty list? <mange>It should still go through a code path in fold-services which tries to apply the extend function from your target service, which should fail if it doesn't exist. <loquatdev>Weird. So, there isn't a way to implicitly (might be the wrong word) declare a service inside another service? <loquatdev>I don't really want to "extend" greetd-service-type, I just want to pass it an already generated configuration so that the user (me) doesn't have to do (modify-services) to change one TTY. <mange>I don't fully understand what you mean by that, but in general no. Service types define an extension interface, and that's the only way another service type can interact with them. <loquatdev>Alright. I'll figure something out, then. Thank you. <apteryx>is it me, or the hooks don't update in git worktrees? <apteryx>my top tree is ~/src/guix, current worktree ~/src/guix-master; running 'make' leaves me with a stale ~/src/guix/.git/hooks/pre-push <apteryx>ah, it's because we have some guard that disables the copy when .git is not a directory <mra>i finally have enough free time to make an effort at getting it merged again. not sure if i should poke ludo too <apteryx>mra: hello! oof, it's been a while; what's the latest status? IIRC the requests from civodul meant you're solution would still not be enough to safeguard against the cases we wanted to be protected from? <mra>apteryx: i'm pretty sure that i addressed civodul's concerns? he seemed to be concerned about performance, but i'm reasonably certain that these changes should have minimal performance overhead <mra>basically because each derivation only checks its direct inputs, so it's not like we're constantly doing traversals of the entire dependency graph <mra>i think that what you're referring to is basically that he suggested that rather than what i implemented, it might be simpler to implement a simple block-list. that's what he's referring to in his comment about a block-list not propagating to descendents <apteryx>mra: OK, thanks for the info, I'll try having another look <apteryx>if you could perhaps come up with 'strace -c' measurements that'd probably be good to put the cost penalty into concrete numbers <apteryx>re git hooks and worktrees; I pushed 427b8f960ec that should address this <oliverD>when i try to install packages i keep getting errors like this: <oliverD>guix install: error: profile contains conflicting entries for glib <oliverD>guix install: error: first entry: glib@2.83.3 /gnu/store/jfr4nl0c2sg6p3wxl3jsf3n5v9s29zkm-glib-2.83.3 <oliverD>guix install: error: ... propagated from dconf@0.40.0 <oliverD>guix install: error: ... propagated from flatpak@1.16.3 <oliverD>guix install: error: second entry: glib@2.83.3 /gnu/store/wvykg0f5nyfyav7k3pc0pdjpz8yks58j-glib-2.83.3 <oliverD>guix install: error: ... propagated from gstreamer@1.26.3 <oliverD>guix install: error: ... propagated from gst-plugins-bad@1.26.3 <oliverD>hint: Try upgrading both `flatpak' and `gst-plugins-bad', or remove one of <oliverD>This is after after running guix pull and trying to run guix package -u to get up to date. <apteryx>oliverD: propagation conflicts; did you try what the hint says? <apteryx>or bring your whole installed package collection to the same revision of Guix that you have; e.g. 'guix upgrade' then retry your 'guix install something' <mra>apteryx: cheers! are you suggesting that i run strace -c on the test suite or something? <oliverD>I tried removing flatpck and then upgraded both at the same time <apteryx>mra: since the new distributable? property needs to be checked transitively for all input derivations, I'd be interested in seeing the performance cost (in terms of syscalls/memory/time used) when it's exercised on a package having many many inputs, e.g. libreoffice <apteryx>this is where we could perhaps see a difference <apteryx>so measurement with change added, vs before change <apteryx>mra: it looks like since the new logic (every distributable-derivation? ...) runs for every `derivation' computation, then it should be possible to test it with ,time and ,profile from the REPL <apteryx>mra: I wonder if something like '(with-store store (run-with-store store (package->derivation libreoffice)))' would exercise this code path <apteryx>with your change, I think: ,time (with-store store (run-with-store store (package->derivation libreoffice))) => ;; 4.149085s real time, 8.421201s run time. 4.978813s spent in GC. <apteryx>before your change: ;; 0.878166s real time, 1.377716s run time. 0.625966s spent in GC. <apteryx>not an acceptable performance penalty to impose on everything every time just for the odd zfs not distribution case :-( <Rutherther>why does that even have to run at our side? why doesn't the server ensure it doesn't distribute it? <apteryx>Rutherther: hm, good question. I think the change was made for (guix publish), but it seems to always be on the derivation path <mra>apteryx: sorry for the slow reply. that is indeed a *really* bad performance hit. i'm surprised that it's so bad! <mra>that's obviously unacceptable as a performance penalty, yeah <mra>Rutherther: the server does ensure that it doesn't distribute it, unless i'm misinterpreting your question <Rutherther>sure but then why does it run at all when calculating derivations? <mra>because that's the only point at which the inputs of the derivation are known, and we need to check that we can distribute the derivation's inputs as well <Rutherther>is it? you can check the inputs retrospectivelly from the store path references <mra>oh, right. so you're saying that instead of making a change to derivations themselves, the change could be restricted to (guix publish) <mra>that may be possible, although i'd have to think about it. but then it's not clear to me how non-distibutability could be propagating <Rutherther>also if the information is supposed to be propagating further and further... why not check only the direct inputs? because their derivations should already have the information. Or is that what is done? <mra>yeah, that's the idea. because derivations are "tainted" at time of construction, it's only necessary to check direct inputs <Rutherther>so it does only that, but still has such a performance overhead? <mra>yeah, that's why i'm so surprised that the performance is so bad. i would expect traversing the entire dependency graph to have unacceptably bad performance, but i'm surprised that even just checking direct inputs still causes such a performance hit <Rutherther>mra: re: but then it's not clear to me how non-distibutability could be propagating. I am really not sure it can be done simply. But maybe for this information it might just be better to create an sqlite database for the publish with this information as sort of a cache <mra>Rutherther: rather than having some kind of central database, the data of whether or not a particular derivation is distributable is stored within the .drv file itself <Rutherther>mra: yes, but that comes with a performance hit, hence why I am thinking of alternatives just for the publish <mra>yeah. i expect that the current performance issues are mainly just the I/O overhead of reading all of the .drv files for every single input <mra>i'm not sure if there is a simple alternative. i do wish that it was possible to just add a simple block-list, but as ludo mentioned that doesn't work because it's not propagating <rustyguix>untrusem: efraim: apteryx: some note about rust 1.91. I initially ran into a SIGSEGV while compiling regex-syntax. The backtrace suggested setting RUST_MIN_STACK=16777216. I noticed in rust-team branch this phase is commented out for 1.91+. Strangely, when I retried the build it succeeded. Is this a known intermittent issue? Should RUST_MIN_STACK still be set? <untrusem>rustyguix, thanks for opening the issue, that would be better <untrusem>you should tag efraim and apteryx as well <rustyguix>yes, ok, i ran into the issue in the past, and had added the RUST_MIN_STACK line for this reason, but so far the upstream rust-team branch had been working. Just ran into the issue again with one build, and cannot reproduce the error. <apteryx>mra: my benchmark was on very fast NVMe storage, FWIW <rustyguix>untrusem: thanks! Tagged both efraim and apteryx <efraim>I left it in the code but commented out in case we do need it in the future. I'm not sure why it is only needed on some machines and not others. And I don't understand how rustc came up with that number specifically <rustyguix>efraim: yes, I don't know either. I am scanning some of recent CI job failures to see if the error happened there. Otherwise I only have had the issue on a Fedora 43 system. <efraim>hmm, wine-minimal for armhf seems to need a compiler that can target armv7-w64-mingw32 <efraim>... but it doesn't for i686? I need to look at this more <efraim>i'm putting this down for now, it's far outside where I was actually working <yelninei>sneek later tell civodul: Whtats the status on a new gash release? <theesm>is it just me or is PR creation via agit to codeberg a bit unstable today? <untrusem>what should be the title of issue for a package upgrade that was overlooked but someone committed directly it to the repo without opening a pull request? <yelninei> ./generated/hurd/debug/32/dmd --version: DMD32 D Compiler v2.112.0-466-g0a24b883f5-dirty. It does not work quite yet though <janneke>yelninei: dmd, is there a dependency on D somewhere? <janneke>ACTION failed to `guix pull --url=$HOME/src/guix/master` yesterday because automake-1.17 now seems to be a dependency, and doesn't seem to build? <yelninei>janneke: No, i am just having fun trying to make gdc work and making dmd work is my stresstest for druntime <janneke>vaguely quoting cwebber: having fun is a revolutionary act <yelninei>janneke: the annoying thing in druntime was porting the libc headers and dealing with subtle bugs assuming CRuntime_Glibc == linux+glibc and not just glibc <yelninei>janneke: on what system do you ahve the automake problem? <janneke>...but i even didn't wait for it to fail, i figured that as there were no substitutes... <janneke>yelninei: nice; and i'm quite patient; happy to "wait" for when you're ready to upstream! <janneke>yelninei: if you're working towards something, "guix pull?", i'm also happy to "wait" for that and include that in the blog post, wdyt? <yelninei>janneke: my branch just ignores the problem that causes the hang, id rather try to fix the cause but am not sure what it is excepet maybe something with the intr-msg-clobber.patch but this does not work <janneke>yelninei: sure, of course. have you checked if the test runs on debian? <janneke>ACTION found that debian doesn't even run many test suites on hurd <yelninei>janneke: Then there is also the problem that guile-git segfaults cloning the guix repository because the progress printer callback gets gced and I am not sure what to do about that <janneke>yelninei: right, but pulling from a local branch should (still?) work, right? <yelninei>i guess yes. But its not just automake, but also libtool, cmake, python, openssl, glib which you all :) <janneke>yelninei: when something like this hang you describe happens to me, i usually ask #hurd if it rings any bell <janneke>in the past it occurred several times that we missed some crucial glibc patch, although i believe they've really started to make an effort to upstream important stuff sooner <yelninei>janneke: If you look at my branch util-linux tries to get the ncursew cflags with `ncursesw-config --cflags` in a subshell. In guix ncursesw-config has its shebang removed to not keep a reference to botostrap bash and somehow the bash fallback to treat it as a shell script anyway fails <janneke>ACTION really wouldn't know where to start to look, other than in #hurd? <janneke>sometimes civodul has good ideas and he's also quite knowledgeable about the hurd; but apparently not here atm <yelninei>i asked in #hurd once but I think nobody saw it <janneke>yelninei: you can also always write bug-hurd@gnu.org, if you have enough specific information <yelninei>and then i got tired of testing libc patches because I did not want to wait hours to rebuild the entire image <yarl>I wonder. I use git worktrees. One of them is at master. When I want to fix something, I create a new one. I edit then I "./bootstrap && ./configure && make", then I can "./pre-inst-env ...". <yarl>I mean re-building for every little fix. <yarl>Maybe copy pre-inst-env with paths updated? <futurile>yarl: yeah, this is what I do. You're supposed to build all of guix and do a test 'guix pull' everytime you push right - so I land-up with long-running 'worktrees' and then once every N days pull into the worktree/rebuild/blah blah <futurile>yarl: a full bootstrap/configure/make or make-clean-go/make takes a while - I haven't found a quick way to deal with <yarl>futurile: I'm trying something. <janneke>yarl: i'm copying over all .go files and touching them, before ./bootstrap; configure; make <janneke>however, you need to be careful or could be creating interesting puzzles for yourself <yarl>janneke: What about doing only "./bootstrap && ./configure" then amending GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH in pre-inst-env and you don't make, you'll get a small portion (what you edited) interpreted. <janneke>yarl: you're even more daring than myself, i like that :) <yarl>Actually, that's only GUILE_LOAD_COMPILED_PATH that need amendment I think <yarl>The sanity check need to be commented too. <yarl>janneke: I got something working with a tiny example. You have a worktree at master in $MASTER. you want to fix package hello. create a new worktree. run "./bootstrap && ./configure" in it. in pre-inst-env, replace in GUILE_LOAD_COMPILED_PATH $abs_top_builddir with $MASTER. in $MASTER run make --touch. edit package definition (e.g. "Example GNU package FIXED!"). run ./pre-inst-env guix search hello <folahtt>Oh nice. This channel exists. I just migrated an hour ago to this OS and I could use some help. <folahtt>I don't know how to use any app on this OS. I installed icecat with guix package -i icecat, but I can't run icecat for example. <ieure>How are you trying to run it? <bdunahu>do you need to source the guix profile? In section 5.2 of the info manual, it describes a shell script in $HOME/.guix-profile/etc/profile <Rutherther>bdunahu: yes, but that happens automatically on log in through a script /etc/profile.d/zzz-guix.sh on foreign distros and /etc/profile on Guix System <Rutherther>bdunahu: don't forget to relog when you add something that introduces a new search path <bdunahu>yes, you would need to resource it if it is the first package you installed <bdunahu>I have no packages installed through guix-profile, and my file contains no environment variables. <folaht>Okay, I managed to get icecat, ungoogled-chromium and hexchat working. Now I installed telegram-desktop, but can't run telegram-desktop. <yelninei>mmh i think dmd works but it segfaults in memcpy when writing the static libphobos because the buffer it is trying to write to does not exist anymore <folaht>How do I run telegram-desktop on guix? <untrusem>you just do `guix install telegram-desktop` <folaht>The issue is that I can't run it. <folaht>How do I check if it's installed correctly? <Rutherther>so what happens when you run it if there's no error? it just exits right away without anything? <Rutherther>Presumably you are running something else than "Telegram" then, being the executable that the package provides. The large t is important <Rutherther>folaht: I didn't ask for an error of telegram. I asked for any error <folaht>Is there a graphical package installer for guix, like synaptic? <identity>folaht: there is an interface to Guix for GNU Emacs <yarl>janneke: after thinking about it, it's better to copy. <yarl>simpler and less error prone <identity>definitely unlike (what i would imagine is) synaptic, but still a graphical interface <ieure>folaht, Many Guix users (myself included) use Guix Home to manage packages in a delcarative way, so the packages are in a source file in my dotfiles repo. <ieure>folaht, There's no wrong way to use Guix, but there are different ways, and I'd say a lot of folks prefer the declarative style over imperative package management. <folaht>ieure, I'm very new to this concept. All I wanted was to get away from Manjaro, despite actually loving that distro. <identity>i would like to see a GUI for guix home-style declarative package management, actually <folaht>But I feel like I've been thrown into the deep end. There's a lot of stuff missing from what I'm used to user-friendly Manjaro. <ieure>folaht, Yeah, Guix is wildly different than nearly every other Linux distro, so skills with those are much less transferrable to Guix. <ieure>I kept Debian on my daily driver, but put Guix System on a spare laptop to get comfortable with before I switched fully. <ieure>I still think that's a good approach, assuming you have a spare laptop. <folaht>I don't, so diving in is what I've done. <identity>installing Guix on your main machine will force you to learn how to use, which may or may not be a good thing <folaht>I just figured out how to extend the menu bar to multiple monitors, so at least I've got that. <redacted>You can install Guix as a package manager on another distro. That's how I learned before transitioning. <redacted>Guix can create containers and VM images from an OS declaration, so you can test out Guix in a container or VM on a different distro. <aaavigatori>Hello everyone, I am trying out guix system in a VM and I am noticing some strange things and just wanted to know if I am doing something wrong. After I've completed the installation and log into my account I have no `$HOME/.guix-profile`. The manual claims that this is autogenerated when the user account is created. Also, when I install a package, <aaavigatori>like e.g. `guix install emacs` I get the message `hint: consider setting the necessary environment variables by running: [...]`. The manual says this shouldn't happen on guix system. <redacted>aaavigatori, are you using a Wayland compositor? I remember having some issues with profiles because of differences in the way shell rc files are sourced differently with Wayland compositors. <identity>aaavigatori: is .guix-profile present after running guix install emacs? <mra>apteryx: yeah, running the test on my machine yields similar results. i assume that the slowdown is just the filesystem I/O work of opening a file for every single input to the derivation <mra>unfortunately, it isn't clear to me that there's a tractable way to solve this <aaavigatori>redacted, yes wayland. It seems to be the gnome default. <aaavigatori>identity yes, afterwards it is present. I was just wondering if I misses a step doing installation <redacted>I'm checking my dotfile git history to find where I fixed something like this. <aaavigatori>redacted I am using bash. BUT! it is working after installing a package and logging out and in again. <redacted>Oh, nice. Guess it was something different <redacted>which is good, because I can't find what I was talking about <aaavigatori>I installed emac, got an error, relogged and installed emacs-geiser and emacs-geiser-guile. For thoese two I got no error. Then I installed git and got the hint message about setting the environment variable again. However, `$HOME/.guix-profile` exists now <redacted>I *suspect* your shell is failing to source /etc/profile on login somehow <redacted>I think /etc/profile isn't getting sourced <redacted>Hmmm, not sure what the analogue of zsh's -o SOURCE_TRACE is in bash <redacted>Lines 32 to 46 in /etc/profile is where your user profile is sourced. <redacted>It's possible your display manager isn't running bash as a login shell. <redacted>I actually have to get back to work. If you can't figure this one out, dm me! <futurile>yarl: if you write a script for improving the workspace modules usage I'd definitely be interested! <redacted>aaavigatori, I think I *didn't* solve this problem for myself! <redacted>I'm not actually sure why my system functions. <redacted>crazy guess, but is your compositor installed to your home profile or the system profile? <yarl>futurile-afk: the workspace modules? <aaavigatori>How do people here manage secrets in their system definitions? <ieure>aaavigatori, Guix doesn't have a way to do this, unfortunately. So I don't put them in. <aaavigatori>ieure so in your system definition you just use fake passwords and change them after setup? <ieure>aaavigatori, I use no passwords at all and re/set them during (for disk encryption) or after (for accounts) installation. <ieure>aaavigatori, Clarifying, I use passwords. I just don't put them in the declarative configuration. <ieure>I would really like a better solution to this. <ieure>untrusem, What's your problem? <ieure>untrusem, Not sure exactly, but the error I think points to your substitute* call being lamformed. I don't see anything obviously wrong about it, though. <ieure>untrusem, Do all the values in that dict need to be pointed to inputs, or just the two in your list? <untrusem>I am currently only testing with these two, all values would be inputs in the end <ieure>untrusem, I would recommend eliminating the for-each and binding the substutute* match. ex: (substitute* "offutils.py" ((": \"[a-z]+\"" _ program)) (string-append (search-input-files ...))) <ieure>Mm, I messed it up, it should be (substitute* "offutils.py" ((": \"([a-z]+)\"" _ program)) (string-append (search-input-files ...))) <ieure>You can bind variables to the groups in the regexp you give to substitute*. The syntax is (regexp grp0 grp1 grp2 ... grpN). grp0 is always the 0th capture group, which is the entire matched string. <ieure>If you group the [a-z]+ match, you can capture it, then give it to search-input-files. Then you don't need the loop. <aaavigatori>can I adjust the UID and GID for the user inside `guix shell --containter`? <ieure>untrusem, If you launch a Guile REPL and use (guix build utils), you can call (substiture* ) manually, and use that to figure out what exactly you need. Note that it changes the file you give it, so keep a copy. <untrusem>i see thanks, I knew about groups but not guile groups, I did see `_ command` invocation in guix repo but didn't know what it was <ieure>Yeah, the _ is a placeholder. It's a symbol, but it's communicating to human readers "this is not used."