IRC channel logs
2024-10-12.log
back to list of logs
<retropikzel>I have added search path to my packages, it works in guix shell and system. But the value is not set when I use guix as package manager, which seems logical, but I would want to have the env var there too. What would be the right way to set it? <jaft_r>retropikzel: is it only the executable which needs the var.? You could always use ~wrap-program~ to have it be present when calling the executable. <retropikzel>jaft_r: It's for library source files. What if I check in my bashrc if it is set and if not then set it? <jaft_r>retropikzel: that seems likely to work, I would think (given it's just an env. var.). <jaft_r>retropikzel: actually, one more question: are you always launching it from a terminal? If you, you may want to put them in =.bash_profile=, instead, as that sets env. variables for the entire session you're logged in (as opposed to just within the shell, like =.bashrc=). <retropikzel>jaft_r: Terminal 99% of the time. But now my problem is that using if in bashrc sets the variable but it does not change when I run guix shell with the package <jaft_r>dth0x: unfortunately, it doesn't really solve what you're seeing but I get back libreworld, when I run it. <jaft_r>Running "guix search librewolf" in my terminal lists the package libreworld, rather than returning nothing? <jaft_r>(why did I keep spelling it libreworld…? Anyway, you figured out I meant librewolf) <Rutherther>dth0x: are you sure you are on recent version of guix? librewolf is not there that long <guix-newbie-123>Hello, when i try to reconfigure or build my guix system I get this error message: guix system: error: failed to load 'sys-config.scm': Read-only file system <guix-newbie-123>I do not understand the error message. What does this error message want to tell me? Which file system is supposedly read-only? <dth0x>Rutherther: you right my version was old <jaft_r>Hey, guix-newbie-123; can you provide the full command you run when trying to reconfigure or build your guix system? That might provide extra, needed context. <guix-newbie-123>I run build or reconfigure like this from a git repository in my users home: sudo guix system build sys-config.scm <jaft_r>Hmm; is any unexpected part of your file system read only, that you've noticed? I expect you probably would have but asking, just in case; sometimes the OS will kick the hard-drive to read-only if it encounters errors, as a way to stop things from getting worse. <jaft_r>I had a hard-drive which was probably failing and it'd suddenly turn read-only while I was using it. <guix-newbie-123>jaft_r I seem to have /gnu/store mounted read-only, according to my understanding that is to be expected though as guix-daemon would remount it in rw? And some /var/cache/fontconfig, but i assume this is not related to this error. <jaft_r>Yep; as far as I'm aware, that's all correct. Welp; I'm not sure that I'll be able to spot the issue but provide your sys-config.scm file (or, at least, as much as you feel comfortable sharing in a public place like this) in a paste site and, maybe, the full error you get (assuming it's longer than just the one line), as well. That may help figuring out what's going on. <jaft_r>guix-newbie-123: of course; I'm afraid I have to log off in a few minutes (and I'm not entirely certain what's wrong) but, those mapped-devices, would you be able to remove that section and try reconfiguring? I'm not sure what it'd mean but I'd be curious if that's a possible source of the error. <guix-newbie-123>jaft_r ill try to build it. I removed the just mapped-devices list, but this did not change the error message in any way. <jaft_r>guix-newbie-123: Ooooooo. K. Hail Mary before I run out of time: put the mapped-devices back, delete the last parenthesis at the very end of the file, and try a build, again. <guix-newbie-123>jaft_r I can remove on two three or more parentheses. No change to the error. This system is busted, shoult i just reinstall? <jaft_r>Wait; one more attempt. Are you able to put back the parentheses you removed? I think your issue, actually, is you added one too many on the line with "%default-authorized-guix-keys". <jaft_r>"bootloader", "swap-devices", "mapped-devices", and "file-systems" should all be a part of "operating-system" <jaft_r>And that's the real error (I'm guess, until we can verify), rather than too many parentheses at the end of the file. <jaft_r>And that would probably explain the error, as well. <jaft_r>It's saying it's a read-only system because you aren't providing any partitions, etc. for the operating-system to use. <guix-newbie-123>jaft_r Thank you very much for the hints and your assistance! I'll try that. <guix-newbie-123>jaft_r I checked that the paranthesis are balanced. But this did not fix it. I still get the same error. <jaft_r>Hmm; put it in a new paste? I wanna take one last look, before I go. Can't guarantee anything but just in case. <jaft_r>guix-newbie-123: O. K. The parenthesis thing would've needed to be fixed, at some point, so that was good but I think it's the with-output-to-file portion that's causing the error (and would explain why any other possible error hadn't been detected yet, since it's so early in the file) <jaft_r>I removed that and, when building your file locally, ran into a new error. <Rutherther>guix-newbie-123: can you share the whole command you are executing and in what folder you are? That error message is the only thing in the log, nothing before it? <Rutherther>oh. You shared the whole command, I missed that. <guix-newbie-123>Rutherer I am in ~/Projects/system-setup running sudo guix system {build,reconfigure} sys-config-red.scm <tplaten>I did not use Guix on my main computer for a long time, now I am doing a guix pull <guix-newbie-123>jaft_r I also removed that and then get some service dependencies that are missing. Is there a better or canonical way to manage system channels? <jaft_r>guix-newbie-123: I generally just keep one channels.scm file (for all profiles) at ~/.config/guix/channels.scm. I don't think you need a separate one for just the system profile (not to generate it, like that, either; just the one file should do). <jaft_r>But I can't speak to how others do it, I'm afriad. <guix-newbie-123>jaft_r I always considered the channels part of the configuration and thought that channels for home and system would be handled separately. <jaft_r>Which is fair; I don't think either is necessarily more right than the other: I just never had. Unless two different channels have the same name for different packages, I never saw a reason to have differing channels for different profiles. Even if you never use packages from a particular channel in a specific profile, the availability of that channel doesn't affect anything. <jaft_r>Having just one file is just more straight-forward, for me. <robin>jaft_r, that works for "sudo -E guix system reconfigure" etc? i was poking around the code, it looked a bit like /etc/guix/channels.scm was hardcoded, maybe not though <Rutherther>guix-newbie-123: you can guix pull -C on your channels file or guix time-machine -C <jaft_r>robin: I always just use "sudo" without the "-E"; I forget where I read it (and, therefore, the explanation why) but it was recommended that "-E" shouldn't be used (I'd been using it, before I came across it) <jaft_r>(*that last "it" being the recommendation) <guix-newbie-123>jaft_r Thank you! I don't want to take more of your tike, I will try to recreate the sys-config in a vm using a different machine. If that works i'll just reinstall, as the system is not important. <Franciman>hi, is there anyone running guix on a thinkpad t460? <guix-newbie-123>jaft_r FYI: After removing the channels writing and removing the additional services configuration, the system builds again. So the issue is definetly the configuration itself. <Franciman>another question, is there any news regarding the jemalloc regression that makes telegram-desktop segfault? <tplaten>no code for module (android import repo) <jakef>is android in your load path? you might need to start the repl with -L android <Rutherther>tplaten: can you run "guix describe"? Are you sure the guix you pulled with the channel is the one you are currently using? <ekaitz_>ugh my system is building gcc-14 for riscv and it's taking more than 12h already <ekaitz_>is this normal? I have compiled gcc in a couple of ours in the past, even with emulation <tplaten>Generation 8 Oct 12 2024 10:27:59 (current) <tplaten> commit: 795f11d4305bb7ce9a2e79669fe8cb4673a9d0c2 <Rutherther>oh... please don't send multiple lines in irc. It is a line based protocol. Your messages are getting deleted and you could get banned. Use paste site <tplaten>I did not think about that, and will use a paste site in the future. <mfg>Hey has someone had a look at #72506? <luca>How can I build and run tests for a given package? <Rutherther>luca: could you clarify? the tests are ran every time when you build it, and that can be done with guix build for example <luca>Oh thanks, I didn't realise that <pjals>Hello. How do I sign an EFI image made by grub-efi-removable-bootloader in the operating system configuration? <Rutherther>pjals: I don't think it is possible with grub-efi-removable-bootloader itself, if you wanted to do it out of configuration you would probably have to change the bootloader / make a new one <Rutherther>by change I meant the source of it, not to change it for another in guix. as far as I know, there is no efi bootloader in guix that would be capable of signing <nckhexen>pjals: Signing bootloaders (kernel modules, anything) would require a Good Think about secrets in general, so they don't end up in the store. This isn't a solved problem upstream. If you don't care about that, the problem becomes simpler but you'll still be writing your own code. <Rutherther>nckhexen: I don't really understand why that's a thing to think about here. The bootloader is installed only in activation phase, and copied to the esp partition in this case. Signing on activation means it runs outside of the build context, so no need for keys in the store at all, just a path to keys will suffice. Or am I missing something? <wdkrnls>Dear Guix, I'm getting a "gzip: stdin: not in gzip format" error when trying to create a Guix package for an R package. Does this mean the cran importer is broken? <wdkrnls>I got the recipe with: $ guix import cran missMDA <wdkrnls>Or is this saying there is something fundamentally wrong with my Guix system? <Rutherther>wdkrnls: so you get this when you are trying to build it? that seems like it could be that the source of the package is not in gzip format, whereas it was expected to be <wdkrnls>Rutherther: Yeah, when I run $ guix build -f r-missmda.scm <wdkrnls>I would think all CRAN packages would be quite well standardized. <Rutherther>wdkrnls: how many times have you run the build? - did you get the error twice? <Rutherther>if you get it multiple times, then it seems something could be broken with your connection or guix install. I've just tried importing missmda and it works fine for me, builds right with imported package without any complications. <wdkrnls>This suggests to me that its my system which is borked. <Rutherther>it's strange though. Could you send the full output of guix build with a paste site, that is if there is more than just the error. You can also try running with --source only to see if it is the source (which I would expect it to be, not sure where else gzip would be used. Unless maybe with substitutes) <wdkrnls>I feel like I have had a similar issue in the past when I had not upgraded my underlying guix system recently enough. <wdkrnls>I tried to place the whole output but debian pastebin and another one I found both said they were spam :/ <Rutherther>tar xvf /gnu/store/8hhh4kq5in3zf9k31rcibndjqpj3xrgr-missMDA_1.19.tar.gz <Rutherther>in that case you can try "guix build --source --repair -f ./missmda.scm". If that won't help, then "guix gc -D /gnu/store/8hhh4kq5in3zf9k31rcibndjqpj3xrgr-missMDA_1.19.tar.gz" could work as it shouldn't really be referenced by anything now. <nckhexen>It's not unusual to accidentally HTML when you really meant to a tarball. <silicius>is anyone else experiencing a segfault when launching blender? <nckhexen>Rutherther: If it works as you describe, I guess that'd work. It's not like I've ever booted secure (or have any machines that even can). I've only looked at other distroes long ago and they did it as part of the 'build', but of course that means little. <Rutherther>nckhexen: I mean there are many ways to do it. But I think this would be the easiest one. It's also how folks in NixOS do it with lanzaboote project <Franciman>silicius: i experience segfaults not only when launching blender but also when launching telegram <Rutherther>but there it's a bit more problematic as not only systemd-boot is signed, also nixos kernel is. I suppose that with grub you don't really have to sign the rest as it just boots whatever and doesn't check the signature - which might be a source of problems when secure booting, yeah <silicius>hmm If I run strace -Z blender I see failed openat at glibc paths in /gnu/store <pjals>oh blender? yea that's broken including other programs <pjals>it's a thing with gpu drivers i think <pjals>you're using an amd gpu right? <pjals>it's most probably faulty glibc code caused by an edge case in blender <pjals>mesa's gl library for amdgpu is crapping out and blender doesn't handle dlopen failing i think <pjals>basically it causes infinite recursion in free in libjemalloc <nckhexen>Or is the faulty Mesa code path taken regardless? <pjals>i have no clue, the call stack is >500k items long so it is really hard to find the real issue <pjals>i've tried to run blender with software rendering and it's the same thing so maybe it's not amdgpu <silicius>it's possible to replace the glibc used right? I'm building @2.30 rn <pjals>--with-input=glibc=glibc@ver i think <pjals>if you don't want to rebuild the world use --with-graft instead <nckhexen>My segfault is also in jemalloc, so we're probably talking about the same thing. <silicius>glbic build @2.31 fails and @2.30 stalls, trying 2.29 <nckhexen>No mention of Mesa though, but the caller is __tls_get_addr and any mention of threads make me brain hurt. <pjals>Maybe blender is using a bundled jemalloc even though we gave it jemalloc? <nckhexen>That's a reasonable hypothesis. The backtrace mentions /gnu/store/j1dpz07vh9wagksidqjqbckh7ihn6hl6-jemalloc-5.3.0/lib/libjemalloc.so.2 explicitly, but I don't know if that means anything. <nckhexen>I've seen glibc's ‘linked’ in that were… wrong. <pjals>Apparently, Blender doesn't bundle jemalloc and relies on a reasonably sane CMake script to find it (as sane as CMake can get) <nckhexen>If it were mixing calls to a bundled & non-bundled one, that would presumably be even worse. <pjals>gdb blender, type in run, and then type in bt, make sure to have some available memory <pjals>bt full if you're feeling lucky <nckhexen>The gotcha is that ‘blender’ is a wrapper shell script, so I just edited a copy to invoke gdb --args. <nckhexen>pjals: I think ‘some available memory’ is the reason I didn't get a full backtrace. I think. <nckhexen>Still, this machine is as Intel as it gets. <pjals>my machine is as AMD as it gets :P <pjals>which is probably worse than intel, considering what i needed to do to get it running <nckhexen>These machines used to be in the Goldilocks zone for libre software support (before Intel GPUs became as broken firmware-wise), but I'm starting to wince every time Mesa decide to ‘modernise’ their codebase. <[>what generation did intel GPUs start requiring nonfree firmware loading? <pjals>It seems like people are having these problems in another seperate part of Blender (bpy), and the solution seems to be building disabling jemalloc. Gonna try that. <silicius>could not build older glibc, it either stalls or fails <nckhexen>Wasn't it Skylake? I dunno. I didn't mean to imply that I follow or care about the latest development like a ~gamer~. <pjals>If someone has a beefy machine, try `guix shell --with-configure-flag=blender=-DWITH_MEM_JEMALLOC=OFF blender -- blender` and see what happens <pjals>By the way, how does Guix get the progress of the build? It seems like magic. <nckhexen>pjals: Have you successfully grafted glibc? I haven't tried, but I'd have expected pain of some description. <pjals>No, not really. I assumed it would work <[>I don't care about anything newer than haswell yet but ME version 11 (skylake, kaby lake, some coffee lake) has a bug that allows you to run your own code in the ME (which also means bootguard can be bypassed) so may eventually become freer. Nonfree firmware being required for the GPU would be another barrier to that. <nckhexen>Oh dear. I see I wrote GPU when I meant CPUs. Sorzy. <nckhexen>We were talking about GPUs and I'm an nckx of very little brain. <[>Franciman: Intel Core i7-4700MQ (which works with fully free software except microcode updates and neutered ME) <Franciman>i don't remember what MQ stands for, but i hope it's enough power for your guix playings <Franciman>is there a way to get debug symbols of a package? <pjals>Power doesn't really matter for Guix, it matters more if you live in a German datacenter or not <nckhexen>Franciman: 4 cores with 8 threads if you're not paranoid. <silicius>pjals: that flag worked, blender launches and works as before <pjals>(god the peering from here to guix sucks so much) <Rutherther>Franciman: some packages have debug output. If not, you can use --with-debug-info transformation. That means it will get rebuilt. <nckhexen>Disabling HyperThreading is strictly more secure than enabling it, and noticeably reduces performance. <nckhexen>How much depends on workload, but it is nice when building softwares, i.e., Guixing. <pjals>I'm assuming HyperThreading means doing preemption on the CPU to make "fake" CPU cores? <silicius>seems the issue with blender was really jemalloc, maybe it's a similar case with telegram? <pjals>I'm honestly lost on what HyperThreading actually is :P <pjals>Franciman: --with-configure-flag=blender=-DWITH_MEM_JEMALLOC=OFF <silicius>Franciman: guix shell --with-configure-flag=blender=-DWITH_MEM_JEMALLOC=OFF blender -- blender worked <pjals>Yes, Guix disables jemalloc. <Franciman> ;; Enabling jemalloc causes SIGSEGV. This probably happened after upgrading to glibc 2.39. <pjals>My solution is using the mobile/web version of Telegram, but that isn't a terribly nice solution. <pjals>Franciman: have you guix pulled? <pjals>Maybe the flag isn't passed correctly or CI is being weird. No clue. <silicius>weird, I don't get any segfaults on telegram-desktop, today's pull <Franciman>i also tried an older telegram-desktop, but i get the same error <pjals>telegram-desktop is working for me though <Rutherther>Franciman: have you tried removing telegram-desktop state/cache files? <pjals>I assume you have also updated your packages from the mechanism you're getting Telegram from too? <pjals>Have you reconfigured your home config? <pjals>Pulling doesn't reconfigure :P <Franciman>building telegram-desktop with debug symbols <Rutherther>any committer could take a look at #73633 ? it is tor browser update that has security fixes, similar ones as librewolf and icecat had in the last days <futurile>hmm looks like not too many people active today Rutherther - maybe jpoiret (earlier though), and Sharlatan did a load of security last night, but I don't think they come to IRC <Rutherther>hmm, although looking more into it it looks like André, who made the patch, is actually a committer, so they should be able to merge it as well, not sure what they are waiting for specifically. I've at least left a review <futurile>Rutherther: mmm, maybe someone to test it - perhaps they'll commit it now you've confirmed it works :) <silicius>anyone knows when python 3.11 or higher will be available? <Rutherther>silicius: there is python-next, so it is _available_. But it's true that packages are currently targetting 3.10, so venv would have to do, and I don't know when it will be switched. <Rutherther>I've tried playing with it on my own channel to get some of the packages working with python 3.12, but it proves very hard since there were couple of breaking changes that lead to mostly every package needing an update, so I kinda gave up with that <silicius>Rutherther: Thanks, I completely missed the package's existence <futurile>python-team has lots of updates in it - it's a bit stuck at the second - it might have 3.12 on it <Rutherther>futurile: even on python-team branch the current package for packages is python 3.10 <adaNewb1234>anyone familiar with how guix's cmake build system integration works? <adaNewb1234>I'm trying to build a package that has an upstream update, but the linker fails. My guess is it has something to do with the rpath being set to a bunch of colons after each other. <silicius>I something similar sometimes when using gcc-toolchain - it does not include pkg-config and so the linker fails when a library cannot be found <pjals>That's why you specify pkg-config in native-inputs. <adaNewb1234>I expect the relevant bit of the command is "-Wl,-rpath,::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: lib/the_Foundation/lib_Foundation." <pjals>Could you build it with Guix and paste the gzipped log that Guix gives you? I don't really want to trust those build logs. <adaNewb1234>since the error(s) are about not finding the definitions of functions defined in the_Foundation. <adaNewb1234>the complete terminal output is more than the allowed 150 KB. <adaNewb1234>the linker error at the end looks identical to me, to the version produced by make in guix shell. <Rutherther>as far as I know the rpath argument should be only passed to the resulting binary and used at runtime. So based on that it wouldn't be able to cause this kind of errors. But I might be mistaken <adaNewb1234>ok, so I just learned about nm, and apparently the functions the linker is complaining about are listed as U (undefined) in lib_Foundation.a <Rutherther>I think the issue is really related to the missing paths, but in a different way. There is a -L before -lunistring, leading to -lunistring being treated as a path to a folder with libraries, but it should be a separate argument that adds unistring. Unistring library contains those references <Rutherther>not sure where that -L comes from, or why it doesn't have path after it <adaNewb1234>might ./lagrange-1.18.1/lib/the_Foundation/Depends.cmake: set (UNISTRING_LIBRARIES -L${UNISTRING_LIBDIR} unistring) be the culprit? <Rutherther>could be if UNISTRING_LIBDIR is empty. Should be set somewhere <Rutherther>in the worst case you can set it yourself in the cmake flags <Rutherther>based on the depends.cmake it likes static library libunistring more. Have you tried putting in the static output of libunistring to the inputs? <adaNewb1234>I am very much a noob at using cmake, and guix. I don't quite know what putting in the static output to the inputs means. <Rutherther>I think that how the cmake depends is written will work only either with fhs or with static library, and static library is searched through find_library which should work fine in guix ecosystem <adaNewb1234>although, I have confirmed: UNISTRING_LIBDIR is empty. <Rutherther>adaNewb1234: instead of libunistring put `(,libunistring "static") <adaNewb1234>um, so far, I have been just using "guix install lagrange --with-latest=lagrange". what bit of the manual do I need to familiarise myself in order to know where to put that line? <Rutherther>adaNewb1234: I thought you were packaging it yourself, or are you just using guix package that is already there? <adaNewb1234>I'm trying to get the existing guix package to update to the latest source version <x8dcc>Also wanted to congratulate whoever made the Guix manual, specifically whoever made all the functions clickable <Rutherther>adaNewb1234: regarding where to put that line - I meant to the package declaration itself. You might be able to get it replaced with --with-inputs transformation, but I am trying myself and just replacing is not enough, both libunistring and static output have to be there <Rutherther>please test it, I don't know what it does at all, and I could maybe send it as patch to guix itself <adaNewb1234>so, how do I build using a new declaration? guix build whatever.scm seems to expect a package name, not a file path <adaNewb1234>although, how do I add it to my current profile? I'm currently running it by invoking the path it listed directly <Rutherther>you can replace build with install if you want to add it to your profile <x8dcc>What package contains the `rm' command? <Rutherther>x8dcc: coreutils or coreutils-minimal. See "guix locate" command for future. <x8dcc>Rutherther: Thank you. I didn't know about "guix locate", but it wouldn't have worked in this case since coreutils isn't installed via guix <Rutherther>x8dcc: I am pretty sure it would've worked since it is pulled nearly to every build, so if you ever did guix install or something like that you should've gotten it in the store as well <x8dcc>I tried it, that's why I said it wasn't installed <x8dcc>No, it just didn't have it installed. It was a "clean" install of guix <x8dcc>When running "guix shell --container libpng [...]", why does it say "libpng16.so.16: cannot open shared object file ..." when running a program linked with -lpng? <x8dcc>I can _compile_ the program with -lpng, but I can't run it <x8dcc>There is a "libpng16.so.16" under "/gnu/store/[...]-libpng-1.6.39/lib/" <Rutherther>x8dcc: the important thing is if there is libpng16.so.15 under /lib or inside one of LD_LIBRARY_PATHs in case you built it for fhs <x8dcc>I see, I am reading the guix blog post now <x8dcc>By the way, are manifests only used for specifying a list of packages? Or can you specify more information? For example to use "--container" or "--emulate-fhs" <f1refly>I'm using greetd. I read that during login, pam should launch `gnome-keyring-daemon --login` that I'm supposed to talk to in my sway configuration file to finish setup. however, when I run `gnome-keyring-daemon --start [..]`, it tells me it couldn't find any other instances, so the keyring is not unlocked and I have to enter my password. Am I doing something wrong? <x8dcc>About my question: If I understood the manual correctly, manifests are only used for packages and their properties <Rutherther>x8dcc: manifests only for lists of packages, no possibility to say to use container/emulate-fhs <Rutherther>f1refly: do you have the gnome keyring service added in your services list that adds the pam library? <f1refly>is that a guix-home component or is supposed to be in my system configuration? <Rutherther>pam is for defining rules on login, like saying if user can log in with password, how to check the password etc. So it would be quite a vulnerability to let users change that <f1refly>I can't find the .so in /run/current-system/etc/pam.d/* though... <Rutherther>I see. So since you are using greetd you should probably also add it to the greetd pam service - so add "("greetd" . login)" to the list <Rutherther>f1refly: the .so are kept in the store, not copied anywhere else <f1refly>it wasn't obvious to me I have to add greetd explicitly, sorry <f1refly>unfortunately, that didn't seem to have any effects :( <Rutherther>and the keychain has the same password as your account has, is that correct? <f1refly>yes, I reset it and made a new one because it was desynced at at some point <Rutherther>alright, in that case I unfortunately do not have any more pointers <f1refly>the "greetd" pam file still doesn't seem to have been created as well <Rutherther>if I am reading the sources right just having greetd-service-type should be enough for greetd pam rule <f1refly>that's also what it says in the documentation for greetd-service-type, but it does not seem to work <f1refly>i keep seeing pam-root-service-type, but I can't find where it's defined <jaft_r>f1refly: in the (gnu system pam) module, file gnu/system/pam.scm in the Guix repo. <f1refly>explains why i can's find it in the services <f1refly>greetd-pam-mount-rules mentions that the path is /run/user/$UID, and greetd-pam-mount says that pam_mount.so should be included there, but I cannot find it, is that a problem? <Rutherther>where does it say pam_mount.so should be included in /run/user/$UID? I am quite sure that is not the case - it shouldn't be there <futurile>x8dcc: you can create a shell script that calls guile/guix, and the manifest from there - so if you want to shorten whatever command you're trying to call <x8dcc>futurile: Right, it's just that I didn't want to add too many files for a feature that nobody else will use. If I add a script, I don't see the need for a manifest in the first place <x8dcc>Don't like it too much, sorry :/ <x8dcc>I am fine with having just the manifest. Again, nobody else is going to use it, and I am not even sure if I will end up using it for much <futurile>ack ack no worries - you're not hurting my feelings ;-) <futurile>just to note - so you're aware - it's a way you can do anything you want using Guile - e.g. setting env vars or whatever - so answers your question about not being limited by guix's ability to accept a manifest <x8dcc>I am not sure if I understood that correctly. You mean that there are some things (like setting env vars) that can't be done without a manifest file? <futurile>x8dcc: guix shell expects the manifest file to be a <manifest> (a list of packages). You can't do anything else with a manifest reasonably. There's also `guix.scm` which can evaluate to a package, which is more flexible but is more complicated. <futurile>x8dcc: using the 'mixed' shell script + manifest that Kaelyn came up, is sort of in the middle. You can do shell scripting (so do things like set env vars), and also define a list of packages (a manifest) to put into the shell env. <acrow`>I modify an existing package that provides a privileged binary at the <acrow`>top of my config.scm file and also redefine the package's symbol to <acrow`>replace the existing package symbol name. When I reconfigure my <acrow`>system the unmodified package continues to be included in <acrow`>/run/privileged/bin though the modified one is in /gnu/store (among <acrow`>other, older ones). Can I fix this by juggling the order of module <acrow`>inclusions? FWIW, the package being modified is slock-1.5.