IRC channel logs
2023-12-19.log
back to list of logs
<apteryx>podiki: I think we free drivers you're probably well covered for that now <podiki>i've been luckier in being able to have my desktop with a wired connection, and dropped a long time ago the vm I was using for that nonfree os....much better on both fronts :) <ulfvonbelow>I get the feeling I will never understand python packaging and its oddities <ulfvonbelow>I'm trying to package python-backports.functools-lru-cache, because it's some dependency deep in a tree for something else, and find that running the test suite causes it to try to download and install setuptools <ulfvonbelow>despite python-setuptools already being provided as a native-input <podiki>some packages, in all ecosystems these days, are really bad at always trying to download dependencies <podiki>lots of patching to remove submodules or hardcode paths instead :( <ulfvonbelow>what's interesting is that according to the error message, the pip invocation is explicitly passing --ignore-installed <ulfvonbelow>of course, there's no mention of any of this in the tests themselves <podiki>frustrating and common these days it seems <ulfvonbelow>there's a single tiny test case, but one of the million toplevel config files python projects have seems to say that it requires setuptools <ulfvonbelow>I just have no idea where it's getting the idea that it must not use the existing setuptools. Surely that's not a default? <ulfvonbelow>it seems to be trying to install it into a virtual environment or whatever python calls it <podiki>no idea...trying to enforce a known version or something, or isolate from system <ulfvonbelow>looks like it's the "usedevelop = True" setting in tox.ini (not to be confused with setup.py, setup.cfg, PKG-INFO, mypy.ini, requirements.txt, pytest.ini, or pyproject.toml...) <podiki>I've enabled zink for mesa, though I'm not sure if it will build on all platforms (hopefully) <podiki>and I think to actually use it you need vulkan too, but not at build and not captured by mesa....I guess someone that uses it will find out if it works at some point :) <ulfvonbelow>... actually apparently it's not usedevelop = True, even after removing that the same behavior occurs <ieure>ulfvonbelow, You shouldn't need that library at all, it's backporting a feature that first showed up in Python 3.3. I'd just patch the dep out of whatever thing thinks it needs it. <ieure>Unless it's ancient and stuck on Python 2 or something. <ulfvonbelow>good to hear I guess, I was just taking the pypi importer at its word <ulfvonbelow>then again that same importer also reported cyclic dependencies <dansa>vivien: I don't understand either. I tried the option --disable-runas-user, but that didn't seem to do anything. I'm dropping this task and considering a possibly simpler one. <dansa>Question. Has anyone ever defined a service for the svscan program in DJB's daemontools package? I see the daemontools package belongs to the Guix repository, but I think there's no service for svscan. In other words, we can install daemontools easily, we but don't get svscan running after rebooting the system. <dansa>If not, then I'm going to learn how to define it. I'd like to have the svscan easily available for the configuration of a system. (I use it.) <ieure>dansa, Probably nobody has done it because on Guix, you probably want to write Shepherd services, instead of using svscan/supervise to do that. <podiki>sneek: later tell vivien zink (as we expected) is a different thing for gtk tests (I guess optional pathway), it needs mesa with zink (now done) and vulkan-loader but I didn't try <ieure>Maybe I don't understand the usecase here, but "manage a collection of services" is the job of Shepherd on Guix; not sure why you'd want to have a Shepherd service that manages a different service runner. <podiki>sneek: later tell vivien so for now I just disabled the failing test on gtk, which you will need on gnome-team when xorgproto/mesa updates hit <podiki>sneek: later tell nckx I think guix-mirror stopped mirroring a couple of weeks ago <dansa>ieure: you're quite right. there is no real point. but I like that service. it's a personal thing. <dansa>for instance, i have some programs already designed to use svscan, so i'd need to translate them all to Shepherd. I might do that. I might not. <dansa>Until then, I guess it makes sense for me to start svscan still. <dansa>But I probably would like to stick with svscan until retirement. <dansa>It seems that daemontools's svscan gets installed at /run/current-system/profile/bin/svscan? <ieure>dansa, No, that's a symlink to the true install location, which is in /gnu/store <dansa>Got ya. But that's what I should use in defining a service? <dansa>In defining the start procedure of a service? <dansa> #:start (make-forkexec-constructor <dansa> '("/run/current-system/profile/bin/svscan 2>&1 <ieure>dansa, See 11.18.4 Shepherd Services in the Guix manual. <dansa>What version is your manual? Mine is on section 10.17.4. <ieure>dansa, That's from the latest one, on guix.gnu.org. <dansa>Omg, things have evolved quite a bit. <davidh38>let us see, whether it still works after restart <apteryx>do we need to patch 'load-extension' procedures in Guile FFI libs? <jaeme>Ok, so I want to update wlroots to the 0.17.0, however, that breaks compositors that require <0.17.0, how does one rectify this? <jaeme>Could one create a separate guix package for wlroots-0.17.0 and keep wlroots-0.16 as well? <jaeme>Because some of the compositors it breaks don't have a version building against 0.17 like river. <benwr>I'd like to run some services in guix VMs. Am I right in understanding that VMs created using `guix system vm` will share the host store? And if so, am I right that this means I shouldn't be cavalier about running everything as root inside the guest? <benwr>(not that I'd do that anyway, of course; we're all responsible adults here... 😅) <efraim>sneek: later tell podki before the most recent updates to mesa I locally built mesa for powerpc-linux and riscv64-linux <vivien>podiki, don’t forget to leave a comment in the source code, so that people merging between branches know to preserve your work <sneek>vivien, you have 2 messages! <sneek>vivien, podiki says: zink (as we expected) is a different thing for gtk tests (I guess optional pathway), it needs mesa with zink (now done) and vulkan-loader but I didn't try <sneek>vivien, podiki says: so for now I just disabled the failing test on gtk, which you will need on gnome-team when xorgproto/mesa updates hit <sneek>Welcome back podiki, you have 1 message! <sneek>podiki, efraim says: before the most recent updates to mesa I locally built mesa for powerpc-linux and riscv64-linux <podiki>efraim: great, thanks. I added a commit to enable zink, wasn't sure if it will build everywhere... it needs vulkan to actually be used I think, but not for building <efraim>I'm building it now on ppc and riscv64, hopefully it'll just work <podiki>i haven't tested it actually works, but it shows as building and we get a new lib in dri (which just links to crocus but is now a bigger file) <podiki>meanwhile I keep manually restarting failing builds on cuirass, very annoying <efraim>the other option is waiting for more stuff to fail and then telling it to restart all the builds <podiki>yeah, might need to do that, but was trying to spot any real failures <podiki>seems the "missing derivation" or just dying with no error are both happening a lot <efraim>yeah, if it fails in under a minute that's normally what it is <podiki>a bunch seem to just fail somewhere in unpacking, like actually fail and not just time out it seems <podiki>or at least shows as fail and log is incomplete <podiki>btw, thanks for your detailed reply on tk and python, a shame it might not be something we can do <podiki>seems it basically couples some essential x/graphics related stuff to python and thus meson too <podiki>although for meson packages need to explicitly add a python input if they need it I think? <efraim>I tried a couple of different ways of inserting `pkg-config --libs tcl tk` but it wasn't being processed during the build <efraim>I guess we could just set it to -ltcl ... and then pass it the includes and lib path as needed but then we're basically shipping it not really functioning if people want to use tcl/tk <podiki>we could then make a python-with-tk variant I guess <efraim>not sure how different that is from python-minimal <podiki>I'm not sure how often it comes up, normally we can hold off I guess and group the world rebuilds, but with all the security updates and grafts earlier it highlighted the dependencies <podiki>python-minimal is used in pyproject/python build system? <podiki>or do you mean more packages should use python-minimal for building? <efraim>no I mean python and python-minimal are pretty close in terms of inputs <efraim>bzip2, gdbm, sqlite, readline, and tcl and tk are inputs in python but not python-minimal <efraim>so python-minimal has more stripped out than just tcl andtk <podiki>so wherever we can use python-minimal would help decouple a bit <podiki>or maybe something between the two that can be used in more places <podiki>anyway, best get to bed over here, thanks for checking in on mesa build! <efraim>I'm looking at the ovmf updates, wow does debian add a lot <futurile>Q: Can you execute a method that's attached to a package record? In the REPL, doing (origin-method (package-source nudoku)) gets me something that looks like a function (<procedure git-fetch...) - I can't figure out how I can execute that function? (eval <thingy?, apply thingy?). Any hints? <attila_lendvai_>futurile, you just need to put an extra (...) paren around it. you only need to (apply proc args) when you want to flatten a list of args as positional arguments to the function. but i think here you will need the store monad around you to invoke that function. but i don't understand that part. <futurile>attila_lendvai: ah thanks for the hint - yeah it executes (and complains about something different) <futurile>ah got it: (define src-nudoku (package-source nudoku)) and then ,enter-store-monad and finally ((origin-method src-nudoku) (origin-uri src-nudoku) 'sha256 (content-hash-value (origin-hash src-nudoku))) <Guest42>What environment variables are used by gcc? <gabber>not sure if that will answer your question but you could try $(guix shell gcc-toolchain coreutils --pure -- env) <Guest42>I'm trying to build Yocto inside Guix and I get an error from configure. <Guest42>| configure: error: cannot run C compiled programs. <Guest42>I think it is the loader that is not working? <gabber>i'd check the configure code to see what the build system is actually trying to do <gabber>and it might be easier to directly define a package and let the GNU build system (or whichever it is) within Guix do it's magic <Guest42>Yocto is complicated, it is not straightforward to me to get to the actual configure script that is failing. Anyway, I think the problem is outside of the configure script. Bitbake is removing all env vars before building anything, which I suspect is what is causing the problem. <Guest42>It doesn't make sense to make a package, Yocto is for building Linux images for embedded devices. The image is not for running on the build computer <gabber>may i ask what your final goal is in the process? IIUC Guix provides many tools which actually replace the whole Yocto shabang (at least to some extent). e.g. Guix lets you configure your whole system in a convenient fashion <Guest42>So, what I need is just what special variables Guix uses for gcc and/or the loader <Guest42>Yes, if it was up to me I would use Guix instead of Yocto, but unfortunately I have a job <gabber>i have a job, too -- and am currently doing something similar with Guix as a build system. <Guest42>Well, in my job we use Yocto. So I have to use Yocto <gabber>if nothing else works you might have luck with containerizing your build environment $(guix shell --container) with exposing the right directory and allowing network and probably emulating FHS -- but that's just an uneducated guess <Guest42>I can get it to work in docker with a non guix container, but I really would like to build natively <janneke>maybe, maybe not. it's (at least part of) your responsibility, as an engineer, to keep up-to-date with the state of the art, and not waste your employers time by upholding the status quo, if something better or more fun is available, imho ;) <Guest42>So I only need a list of which environment variables or other things that needs to be present for the gcc and the loader (and maybe other stuff?) to work <Guest42>Janneke: Guix crosscompiling is also not very good <Guest42>Almost no packages are supported for cross compiling <gabber>that is probably an unjustifiable accusation <gabber>almost everything is cross-compilable. with the --target flag <gabber>you can even natively compile for a foreign architecture with --system <Guest42>Nope, I have tried. Almost every package I added to my aarch64 image resulted in it being unbuildable without using qemu <Guest42>Yes, --system works fine, but is 4x slower <zilti>My machine has built half a dozen Rust versions, two GHCs, and gfortran among probably hundreds of packages since yesterday, and is still not done. All I wanted is a running guix machine... <janneke>Guest42: funny you should say that, i've initiated the mingw cross build and worked a lot on the hurd cross buld -- but yeah, we can always use more help (and bug reports) <gabber>Guest42: have you tried the command i gave you above? it should hint you towards the env vars you need <zilti>nss is running its stupid test suite since over an hour <gabber>zilti: have substitutes become unavailable for you? <gabber>zilti: i assume you did a fresh $(guix pull) and now a $(guix system reconfigure)? <Guest42>well, it was actually for a pinephone pro I tried to cross compile. And it was just the most basic things like shells, terminals, window managers, browsers and stuff like that I added. I had to use an almost empty os definition to bootstrap it and install all my stuff on the phone itself <zilti>gabber: it fetches the substitutes, downloads a small handful of binaries, and builds almost everything from source. I did, yes <gabber>Guest42: $(guix build bash --target=aarch64-linux-gnu -n) tells me it would only download substitutes, not build anything.. maybe substitutes weren't configured correctly? <zilti>guix weather also shows what I assume is the correct output <Guest42>gabber: I thinlk it did some substitutes, but not everything was available <zilti>And I also tried --substitute-urls <gabber>zilti: if a reconfigure takes too much time (depending on the machine i'm at) i wait a few hours (or days) for the substitute servers to catch up and only then do a reconfigure. $(guix weather) and the -n flag are your friends in figuring out how much will be built locally <Guest42>Here is an example: guix build: error: gnu/packages/lisp-xyz.scm:171:2: sbcl-alexandria@1.4: build system `asdf/sbcl' does not support cross builds <Guest42>So I can't have window manager or browser if I want to cross compile <zilti>According to guix weather, 97.6% is built on the servers <Guest42>guix build: error: gnu/packages/audio.scm:2555:2: jack2@1.9.21: build system `waf' does not support cross builds <Guest42>guix build: error: gnu/packages/web.scm:2171:2: serf@1.3.9: build system `scons' does not support cross builds <Guest42>So you see, there is a lot of stuff that is not possible to cross build <Guest42>guix build: error: gnu/packages/emacs-xyz.scm:29604:4: emacs-vterm@0.0.2: build system `emacs' does not support cross builds <gabber>Guest42: i think people are well aware of the fact that not all build systems support cross compilation <Guest42>Ok, I was just trying to prove to janneke that there is actually a problem because (s)he said that cross builds work <Guest42>But, back to my initial question again. Does the loader depend on any variables or other black magic? <zilti>gabber: But is everything fine with my config? Because on another machine I use guix on top of void, and there it uses binaries for packages it builds from source here <gabber>zilti: it is hard to tell without having a look (: but from afar i guess your config is fine ;) <gabber>zilti: are both machines on the same checkout -> $(guix describe) ? <zilti>gabber: I can't guarantee the same checkout, but I guix pulled them both yesterday morning <gabber>zilti: i must have missed that link.. i guess your config looks the same. are the machines the same architecture? you could $(guix describe --format=channels > channels.scm) on the machine that is well and do a $(guix pull --channels=FILE) on the other machine (with the file generated on the first one) <gabber>then the behaviour (given you actually are on the same architecture) should be exactly the same <zilti>gabber: Same architecture, yes. Thank you for having a look at it! I will try that guix describe tonight when I'm home. <Guest42>gabber: I didn't see your above comment: "Guest42: have you tried the command i gave you above? it should hint you towards the env vars you need" <Guest42>I can't find the command you are referring to, can you post it again? <Guest42>Was it this one: $(guix shell gcc-toolchain coreutils --pure -- env) ? <Guest42>I think I have found all the vars used by gcc, but I think maybe the problem now is with the loader <gabber>Guest42: yes, that was the one. i think the problem is with the way yocto builds - in a irreproducible (some might say irresponsible) manner... but i'm no expert of course <Guest42>And the guys in #yocto are blaming you <Guest42>I think both Yocto and Guix are partly to blame <Guest42>I agree that the Yocto build process is bad, but I would just like to get an overview of the black magic on the Guix side of things <janneke>Guest42: i was saying that i have some affinity with cross-builds, that i would like cross-builds to work, that i would appreciate help and bug reports :) <Guest42>So I can possibly whitelist the correct variables or do whatever else to make the Guix special stuff available inside the Yocto build environment <gabber>Guest42: there is no black magic. you are able to find everything that is happening within the repo (if you dare to dive into that) - i'm sorry i don't have any more insight for you. if you managed to get yocto packaged for Guix would be great nevertheless <Guest42>There is no such thing as packaging yocto, it does not make sense <Guest42>It is just all source code and embedded in the repository for the Linux image that is being built <Guest42>I you were to package parts of it as a Guix package it would not be compatible with the source for the image, since they are both part of the same code base <Guest42>The result of a Yocto build is an image to be deployed to an embedded device, you understand how this can not be a package? <gabber>Guest42: this is pretty much the same as Zephyr altough very different in the details <Guest42>I think Zephyr has a more distinction between build system and source code for the image/distro itself <f1refly>Couldn't one use guix to create an image for an embedded device in theory? <euouae>Hello all, I installed cryptsetup with `guix install cryptsetup` but I can't find the binary now <euouae>I already have the lines on GUIX_PROFILE & sourced, I'm on the guix system <gabber>f1refly: of course. this is what $(guix system image) already is capable of <Guest42>f1refly: Yes. But I'm not trying to "create an image for an embedded device". I'm trying to build *this specific* image that is using Yocto. <f1refly>If you find out tell me, I hate yocto <Guest42>lol what, then why would you like to know? <f1refly>I feel like putting a management layer over yocto might improve it somehow if done well? <Guest42>How can I get networking to work fully in a guix container? <Guest42>I made a container with --network, but Bitbake pretends that the network doesn't work. (I checked with wget, and it works for that) <Guest42>Also, how can I make ssl certificates work in the container? <civodul>Guest42: hi! ‘ping’ requires special privileges, that’s why it doesn’t work in the container <civodul>(outside the container it’s a setuid-root program) <civodul>for certificates, you can add the ‘nss-certs’ package to your container <civodul>possibly mapping it to /etc with --export=/etc/ssl/certs=ssl/certs <benwr>Hello! I'm wondering about the easiest way to add a vm as a service to my system configuration. The vm is built using `guix system vm`; is there an easy way to incorporate a vm from such an image into the system's service list? <ineff>Hello everyone, I'm new to guix and I'm having some troubles <ineff>Here's the problems: 1. when I try guix pull the wholes system has to compile certain derivations, even though I'm using the channel-with-substitutes-available in channel.scm file, is this common? Shouldn't channel-with-substitutes-available avoid any derivation build? <ineff>2. After I've updated guix with guix pull, if I use guix package -u the systems downloads a lot of packages that after the updates become marked as dead by the gc, which collect them if I give a guix gc after. <euouae>Hello, how can I install the `file` command? It's POSIX, so I'm surprised that POSIX utilities are missing <ineff>For the sake of clarity I'm using the binary installation of guix on a foreign distro <euouae>the_tubular, thank you! how did you figure it out? <euouae>aha! `guix locate file` -- for me it says bash-completion though <euouae>it's literally `file`, but I'm not sure why guix locate didn't find it <euouae>I got it with `guix install file` <benwr>I think guix locate only works with files you actually have? <ineff>euouae: guix locate use a database build from the path installed into you store <ineff>at least for now, according to the manual <euouae>I don't understand why locate wouldn't find file in the file package <benwr>euouae: if you haven't installed `file`, you don't have its contents locally. `guix locate` (for now?) only knows about things you hae installed already <ineff>euouae: basically guix locale find files in packages that are currently installed in the store of the system from which it gets executed <ineff>it doesn't have a database that keeps track of all the file-packages relations, at least not currently <euouae>does guix graph give strange output or are double arrows expected/ <euouae>e.g. `guix graph binutils | dot -Tpdf > dag.pdf` <euouae>I also noticed that with larger packages such as `emacs` or `gcc-toolchain` it takes a very long time to finish (I kill it) <euouae>is that some dot defficiency or is the output an edge case for dot? <benwr>`guix graph emacs` has 3000 lines in it, I think almost every one representing an edge in the graph, so seems likely that dot is just struggling to lay them out nicely <euouae>What about the text in 9.9 `guix size` on the info manual <euouae>It says `guix size binutils` will be the transitive closure of binutils as returned by `guix gc -R $binutils-path` but I get different outputs <euouae>ah nevermind, they're sorted differently <euouae>but maybe the question stands -- why does `guix size binutils` and `guix graph binutils` list different packages? binutils,glibc,gcc,bash-static versus binutils,texinfo,perl,ncurses,pkg-config <civodul>euouae: try ‘guix graph -t references binutils’ to see the run-time dependencies, which is what ‘guix size’ shows <civodul>‘guix graph’ shows the build-time dependencies by default (aka. ‘-t package’) <euouae>given that guix environment is getting deprecated, should its uses be replaced with guix shell in the info manual? <euouae>e.g. under 5.8 Invoking guix time machine <euouae>oh maybe it is appropriate there because we're time-travelling to an old Guix version <euouae>will `guix pull && guix upgrade` install new kernels or is that specifically from `guix system`? <rekado>“guix upgrade” only updates your current user’s default profile <euouae>yup, but it went as far as installing kernel modules (I think?) so I wasn't sure <euouae>(e.g. with cryptsetup I believe it installed a kernel module) <rekado>you can also have the “linux-libre” package installed to your profile, but it won’t ever be used by your system. <ineff>so .... does guix system basically work like a guix package but for a "system" profile? <euouae>A lot of fun using Guix. I'm glad I'm making the switch, it's a great OS! I got to go, thanks again <civodul>efraim: hey! i was looking at the gsl-static changes <civodul>i think there’s a typo in e440df2a23b72bf7c1bf03d7c0774e0c66b39dea <civodul>it’d be nice to add a deprecated alias for “gsl-static” too <rekado>ineff: I can’t answer the question in these terms. Guix System does use packages, profiles, and files in /gnu/store, but it’s not merely a collection of packages that make up a system. <ineff>rekado: For the sake of clarity, I was talking about `guix system` the command not the OS. Not sure if this does help in any way, though <rekado>“guix system” does more and fundamentally different things than “guix package” <rekado>“guix system build config.scm” is roughly equivalent to “guix build” in that it only produces some /gnu/store location (and whatever is needed by that location) <rekado>“guix system reconfigure” install the built system (by creating a new GRUB entry, switching over the current system, etc) <rekado>it also maintains a system profile (see /run/current-system/profile), but that’s just a small part of it. <ineff>I see, of course it has to manage other things as well, since it needs to handle bootloader and other things that need to be available even before boot. Silly me, thanks a lot rekado <rekado>you can do “readlink -f /run/current-system” to see the store item representing the current system. <rekado>you’ll see that it contains a “profile” link for packages to be installed globally <rekado>but it also contains a whole bunch of other things, such as scripts to launch to configure the service graph, or the init script, etc <rekado>and “guix system [init/reconfigure]” take care of the annoying stateful bits to point GRUB to these files <benwr>Hello! I'm wondering about tailscale. Its client components are BSD-licensed, though they're only useful in conjunction with a closed-source hosted service. Is it potentially a candidate for being added to the guix package ecosystem? <peanuts>"Luis Felipe: "? New Guix caps available in the store ? <podiki>i was eyeing some of the tees for the future <rekado>is it expected that “guix build -m manifest.scm -d” downloads everything the manifest describes instead of printing the derivation? <mirai>IMO the client is still free software and might still be of value were someone to write a free server implementation <zilti>gabber: I figured it out - the substitute servers were unauthorized... <rekado>is it at all possible to get the build derivation for a manifest? In all my tests I’ve only ever been able to *build* or download the packages listed in the manifest. I can’t seem to get a profile derivation. <rekado>when I evaluate “(with-store store (build-and-use-profile store "/tmp/meh" manifest #:hooks '() #:dry-run? #true))” with an arbitrary manifest it downloads everything the manifest asks for. Is this correct for a dry run? <attila_lendvai>udev-rules-union only deals with {package}/lib/udev/rules.d kinda dirs, but what if i specify an inline rule as a plain-file? it silently doesn't work now, but can it be made to work? or at least fail loudly? <apteryx>oof, the recent r changes triggered a bunch of bug#54447 colaterals <apteryx>ACTION painfully restarts them by hand <apteryx>it'd be nice if everyone pushing to master was subscribed to the cuirass notification and catching this kind of "breakage", to have more hands doing this tedious work <rekado>I had built out the whole branch first before merging <apteryx>the broken builds all happened on aarch64-linux it seems <apteryx>either it wasn't built on this aarch in the dev branch, or something was changed on master affecting only aarch64 in the meantime? I don't know. <vivien>attila_lendvai, you have to use a gexp that puts your plain file in a /lib/udev/rules.d sub-directory <vivien>This is very convenient because in the future, you will also have file->udev-hardware for hwdb files <vivien>So you will be able to extend the udev service with either rules or hardware files <apteryx>vivien: I've finally appened my reviewed-by tag on your series btw <apteryx>thanks for working on GNOME! I'm excited to try it. <apteryx>are there owners of TP150N think penguin wifi dongles around? <apteryx>mine stopped working on my Guix Systems, but it looks like it's possibly a hardware failure <vivien>apteryx, I had one too on debian, and it also stopped working <apteryx>if another owner has one working fine on Guix System, that'd rule out a regression in the kernel drivers <euouae>can't you test regression by rolling back apteryx? <vivien>I think I cooked it with an overheating laptop <apteryx>euouae: I think I did try to go as old as I had, 5.2, and it still wasn't working... so yeah probably a hardware problem but I had never experienced this kind of hardware dying on me, so was skeptical <vivien>But that was years ago, so if you had a similar experience now, maybe it’s not linux’ fault <euouae>apteryx: why don't you test it by booting into a livecd? <apteryx>with some other distro to make sure... that's a good idea <vivien>I could try to plug it in again and see, when my cat lets me <ineff>I'm having curious problem. I'm trying to install emacs-minimal inside a profile via a manifest, when I run `guix install` it downloads a series of dependencies that can be garbage collected once the installation has ended; the problem is that if try to re-install the same package on a different profile guix redownload everything despite the fact that the package is already available and installed in the local store <ineff>. Is this the wished behaviour? <vivien>apteryx, dmesg shows absolutely no more input when I plug it in (vs when it is not plugged in) <wcwdcwsadcwdceff>Hello, I'm trying to use copy-build-system to make a simple package, but I need to patch the shebangs. How can I enable the patch shebangs phase in copy-build-system? <wcwdcwsadcwdceff>I found a keyword argument named #:patch-shebangs? in the source of copy-build-system, but setting this to #t did in fact not patch any shebangs <vivien>wcwdcwsadcwdceff, maybe it would be more convenient to use the gnu-build-system and delete the configure, build and test phases, and replace the install phase? <euouae>how do configuration files get managed? <euouae>suppose I had some configuration files that I wanted to drag with me to different machines that I install guix on <vivien>I do that with guix home, in order to maintain my .guile <euouae>just .guile? why not everything? <euouae>how do you transfer these to a different machine though? <vivien>I also maintain .gnupg/sshcontrol and .config/autostart/gnome-keyring-ssh.desktop via my custom service <vivien>(it extends home-files-service-type) <euouae>It seems to me that extending e.g. `home-xdg-configuration-files-service-type` to add a "sway/config" file requires me to have that file <euouae>so I can't execute `guix home` without it -- which defeats the point. Is it possible to embed the configuration files inside the guile script? or in a directory? <vivien>I bet you can use (plain-file "my-super-sway-config" "...") <vivien>(replace "…" with the actual config) <euouae>it would be nicer if there was some better way to distribute them, esp. for big configuratoins like .emas <wcwdcwsadcwdceff>Why do you need it to be one file? I find it much more tidy to have them in separate files <euouae>wcwdcwsadcwdceff, how do you distribute it? do you have a `home` dir that has your assets & `guix home` script and run it? <vivien>euouae, see #62549, #58652, #60753, #64620 <euouae>interesting, it seems that Emacs needs a bit of care to deal with <vivien>Lots of people have opinions about emacs here (who would have thought) <euouae>yeah I'm thinking of giving guix a try for emacs packages <ieure>euouae, I'm using Guix Home to manage that stuff; I like it a lot. <ieure>Have been using straight.el for a few years, I prefer the Guix package management. Much less fiddly. <euouae>ieure, how do you bring your configuration files with you? <euouae>is it like others suggested via a git repo? <ieure>euouae, Yes, my dotfiles have been in Git a long time (and in Subversion before that). I wrote a Makefile long ago, which links everything into the right location. For Guix, I branched my dotfiles repo and wrote a home.scm that has services which do that for me instead of the Makefile -- but it's otherwise more or less like it was. <wcwdcwsadcwdceff>What is the right way to patch references to /bin/bash in other places than shebangs? <wcwdcwsadcwdceff>For example I'm trying to package a python project that calls /bin/bash directly in subprocesses <ieure>wcwdcwsadcwdceff, The substitute* procedure is what you want to use for that. <vivien>Maybe something like this: (substitute* "src/bin/the-script" (("/bin/bash") #$(file-append bash-minimal "/bin/bash"))) <vivien>If the package arguments are a list of gexps <euouae>ieure, nice, thanks. you had the right idea with the makefile <vivien>Instead of #$(file-append …), it is also common to find (which "bash") <ieure>euouae, I love make and have committed unutterable travesties with combinations of make and m4. <wcwdcwsadcwdceff>le we're on the topic, what do you put as a shebang in your own scripts? <apteryx>vivien: interesting, so it appears completely dead for you <vivien>wcwdcwsadcwdceff, each programming language has its own preferred interpreter, you should forget about guix and do what the language expects <Fd9a>Hello. I have a configured build machine. From time to time it is not available and guix build gets stuck in an endless loop of: guix offload: error; process 29413 acquired build slot. Is it possible to make the build continue locally after several unsuccessful attempts? <wcwdcwsadcwdceff>And putting directly the store path is obviosuly wrong too. For now I usually use /urs/bin/env python or similar <ieure>wcwdcwsadcwdceff, Python stuff should always use `#! /usr/bin/env python2', `#! /usr/bin/env python3', or `#! /usr/bin/env python' (if you like being surprised by your program breaking). <vivien>wcwdcwsadcwdceff, it’s the responsibility of guix to fix the shebangs when you build a package around the script. If it is standard, it won’t miss it. <ieure>wcwdcwsadcwdceff, That stuff works fine in Guix, which gives a /usr/bin/env for this exact usecase. <ieure>If you're building a package, definitely prefer the store path. But for personal scripts etc, /usr/bin/env is fine. <wcwdcwsadcwdceff>vivien, what I'm talking about now is when you just make a quick script which is not going to become a package <vivien>If you want to run unpackaged scripts, I suggest you use extra-special-file <vivien>Use the standard shebang, and configure your system so that it provides the interpreter in the standard location <ieure>wcwdcwsadcwdceff, Like I said, just use the normal `#! /usr/bin/env python' shebang <wcwdcwsadcwdceff>Is that allowed? I have thought about it, but for sure there must be a reason why guix doesn't already provide it <vivien>For instance, the Guile manual tells you to use "/usr/local/bin/guile", but it is not provided by default (I think?) on guix. So, you would reconfigure your system with the extra-special-file "/usr/local/bin/guile" pointing to (file-append #$guile-next "/bin/guile") and everything would work <vivien>sorry, (file-append guile-next "/bin/guile") <euouae>ieure, haha. m4 is quite prone to that sort of thing. It's such a powerful and simple idea they had with the macro processor <vivien>You need that kind of thing if your computer is an emacs TRAMP landing zone <wcwdcwsadcwdceff>I don't remeber exactly but I think I configured a path variable inside the tramp config to work around it <vivien>The alternative is to add extra-special files for coreutils (test, ls, cp, mv, rm, chmod, cat) in "/usr/bin/xxx", /bin/find from findutils in "/usr/bin/find", /bin/perl from perl in "/usr/bin/perl", and bin/grep from grep in "/usr/bin/grep" <vivien>And so anyone can connect without having to configure anything <vivien>Guix does not do that by default because it’s unreasonable to assume that on every system, there will be a user that will want to run unpackaged script in every known programming language ever <vivien>Also the next question is what version of the interpreter should be in /usr, so that every user is happy? <wcwdcwsadcwdceff>I have never used that feature of guix. How does it decide which one is one the path then? <vivien>The person writing the system configuration decides <vivien>When you do (file-append guile-next "/bin/guile"), then it will be whatever guile-next tracks <vivien>Yes, but should guix as a system distribution do that? <vivien>The system administrator should decide this kind of things <vivien>That’s why guix does not provide /usr/local/bin/guile by default <vivien>(responding to “why guix doesn’t already provide it”) <vivien>(“interpreters in the usual places”) <wcwdcwsadcwdceff>I fail to see the distinction between making a version of a program or interpreter the default by putting it on the path, and putting it in /usr/bin. If you have it one place you want to have it in the other as well <vivien>You mean, why /usr/local/bin/guile is not in PATH and another guile is in PATH? <vivien>That I don’t know, /run/current-system/profile/bin is in PATH but not /usr/bin nor /usr/local/bin <wcwdcwsadcwdceff>But, anyway. Thats my rant for the day. extra-special-file is a good enough workaround for m <vivien>I guess it is very rare to put stuff in /usr/bin and /usr/local/bin <euouae>so to replicate my system, I save three things, my /etc/config.scm, my `guix describe -f channels` and my home-environment <wcwdcwsadcwdceff>guix describe is only for versions, so not strictly necessary. I keep just my system.scm and my home.scm <euouae>but I use multiple channels, not just guix's <wcwdcwsadcwdceff>And you could even combine home and system in a single file if you wrap them in an if-statement that checks the commandline arguments <euouae>I don't want to introduce state in config files <euouae>Don't you mean it checks $0 and $@? <euouae>I know they're guile scripts but I prefer to think of them as configuration files <wcwdcwsadcwdceff>So you can detect if the config is being applied with `guix system` or `guix home` <wcwdcwsadcwdceff>You don't need to exec the script directly you still call guix system reconfigure <euouae>yeah I made a big deal about embedding configs in the home.scm file because I didn't quite get how to manage them <euouae>but I think I have an idea of how to bundle everything for a Guix system now <vivien>euouae, you can embed your list of channels in your home configuration with home-channels-service-type <euouae>so first I bring up the home environment, and then I sudo guix system reconfigure? <vivien>euouae, you have to run guix pull between these steps <vivien>wcwdcwsadcwdceff, not that I know of. The closest thing is the unattended-upgrade-service-type, which lets you configure which channels are used to automatically update your system <vivien>You could use the extra-special-file function to populate /etc/guix/channels.scm but I’m not sure how you could save your system if one of your channels dies <euouae>Can't you just have a home profile for all the system channels that you switch to when you guix system reconfigure? <vivien>If you have a channel file for the system, you can do sudo guix time-machine -C <your channels file> -- system reconfigure /etc/config.scm <vivien>That’s how the unattended-upgrade-service works by the way, except it’s using /run/current-system/configuration.scm <vivien>(and it’s not doing sudo because it’s running as root) <ieure>I'm also not entirely sure how to manage the nested dolls of bootstrapping a fully-working system, since ex. my home config is in an authenticated repo and has dependencies on my personal channel. I guess I need a bootstrap home config that sets up enough to let me clone the real config and immediately reconfigure using that. <ieure>I definitely gave up on having /etc/channels.scm, I just use my user's channel definitions. <ieure>I haven't encountered a situation where that's the case. <wcwdcwsadcwdceff>Channels that are specific for that users home config is ok, but channels that are needed for hardware support belongs in the system <ieure>I also used to believe this, but I no longer do. <vivien>If you want to reduce the number of channels, remember that you can use -L arguments such as: guix home reconfigure -L extra-services config.scm if your git repo contains config.scm and other guix code under extra-services/ <euouae>got to go, thanks again for the help <vivien>You can even add a .guix-channel file so that your extra guix code can also be used as a service <wcwdcwsadcwdceff>In single user system the distinction is not so important, but if it was a multi user system then it would be completely braindead to have important system channels not be a part of the system <ieure>wcwdcwsadcwdceff, Yes, I also used to believe this, and no longer do. Even on a rare multiuser system, you're going to have an admin -- the hardware stuff can be in their channel, and not the others. <vivien>If you manage your home or system configuration (or both) in a git repository, you can add extra guix modules in the repository. If you use the -L option of guix home (or guix system) reconfigure, you don’t have to provide a channel for your extra code <wcwdcwsadcwdceff>But what if you had multiple users that wanted to reconfigure the system? <graywolf>Hi, quick question, the operating-system documentation states that I should never need to touch essential-services field. How should I remove %linux-bare-metal-service when deploying into an container? <vivien>cbaines, do you know why the revision for #67601 failed? <vivien>[error] LC_MONETARY: field `mon_thousands_sep' not defined <vivien>[error] no output file produced because errors were issued <wcwdcwsadcwdceff>A package I'm trying to build fails because of missing symlinks. I can see in the output from the unpack phase that they are not being unpacked. But if I unzip it manually the symlinks are there <graywolf>Hi, question regarding go: Is there work being done regarding packaging golang 1.21? I am curious if there are ways to help with that. <Altadil>Hi, it appears issues.guix.gnu.org is again not reachable with Tor (at least not working for me). I have not tried to access it in quite some time, so I don’t know since when. <Kolev>GNOME has no Hebrew translation in Guix. <graywolf>Hm, how can I deploy a guix system when using a dummy /? (file-system (device "/dev/null") (mount-mount "/") (type "dummy"))? guix system reconfigure works fine, but guix deploy fails. Any ideas? <dansa>ere's my current situation after having deleted various generations, garbage collected, refreshed packaged, added channels... But I have no idea if this has any connection with the situation. Here's the error message: /etc# guix system reconfigure /etc/config.scm guix system: error: aborting reconfiguration because commit ebcb5c8e120b39a3dd07c27bc17d520ee653ec23 of channel 'guix' is not a descendant of <dansa>d5fece6bfe6b2eaf93f936a4a6dea8fbfe118140 hint: Use `--allow-downgrades' to force this downgrade. <dansa>I don't want to downgrade anything, so I did not follow the hint. <dansa>But I'd like to reconfigure my system. :-) <vivien>dansa, these commits are months ago <vivien>Can you run guix pull (as root since you’re running as root)? <dansa>So, this makes sense --- I had pulled with a non-root user and then tried to reconfigure with root.