IRC channel logs
2023-12-28.log
back to list of logs
<zizitop>In a guix.scm file (for guix shell), how do I ask for a certain version of the C compiler? For instance, if I want the gcc 4.94, how do I ask for it? <zizitop>I searched for gcc-toolchain and found the package (gnu packages commencement), but I don't know how to specify the version in (native-inputs). <tsmish>zizitop: there is gcc-4.9 package in (gnu packages gcc). <zizitop>But I don't know how to ask for it. I tried (inputs (list gcc@4.9.4)) but I get undefined symbol or something to that effect. <zizitop>I'm looking for an example in the source code of all packages. <tsmish>zizitop: in general you can create a new package inheriting the old one and change version/origin. <tsmish>zizitop: (inputs (list gcc-4.9)) doesn't work? <tsmish>zizitop: AFAIK you can't really depend on a version that way, only on specific package. It's just (gnu packages gcc) defines a lot of packages for different versions of gcc. <zizitop>Got ya. You're just giving the idea of actually reading that package to see what's defined there. I'm a beginner --- pretty lost yet. <zizitop>By the way, I should say --- I'm trying to package leafnode, if nobody seems to have done that yet. <dansa>and ``strlcpy.o:15:1: warning: null character(s) ignored''. I believe this is an old package (with no new release) and perhaps the build system is not quite working any longer. Have you seen this before? I haven't identified what the problem is yet, but it does seem to be guix-related because I can compile this package on an Ubuntu system. Any idea what could be happening? Can you spawn a shell to try to compile this package and <dansa>see if you run into the same situation? <tsmish>dansa: works for me. try "guix shell -C gcc-toolchain sed coreutils autoconf automake m4 grep pcre2 gawk make -- /bin/sh -c './configure; make; ./leafnode'" <tsmish>could have sworn there was a way to include default build deps is shell <dansa>Here's what I get after ./configure: checking how to run the C preprocessor... ./configure: line 1513: grep: command not found <dansa>Indeed I'm out of grep here. <dansa>Wait, wait. Stuff's wrong here. <dajole>Apologies for the beginner question. I'm on a fresh installation of Guix and seem to be having dns problems. On other distros I have used, wired connections just worked as long as the interface is up. Any idea what might be going on? <tsmish>dansa: can you put a command you entered and the output you got on paste.debian.net <tsmish>dansa: grep is included in that command <dansa>tsmish: typo on my part. I got it here. Amazing. So I don't really know what it is, but I guess given my beginnerness I should just move on with the right environment --- which you gave me. <tsmish>dajole: I guess check if dns server is in /etc/resolv.conf. If you included %desktop-services NetworkManager should have written it. <dajole>What exactly would I be looking for in `resolv.conf`? I do remember being asked whether to set up NetworkManager during installation and I affirmed. <tsmish>dajole: there should be a line like "nameserver <ip>". <dajole>There is, and it seems to be pointing to my router's ip. Is that expected? I should also add, I am assuming it's a DNS problem as I get 'unknown host' when trying to ping hosts and I don't have a network connection. <tsmish>dajole: does ping <router ip> work? <dajole>Ah, that does not work either. Hm...🤔 Let me double check the cables. <tsmish>dajole: "ip a" should tell you if the interface is up. <dajole>It seems to be down. Weirdly, doing `ifconfig <interface> up` doesn't change its status <dajole>It was working during installation, so it seems unlikely to be a firmware issue (though I don't know much about these things). <tsmish>dajole: is it marked as no-carrier? Can you post the result of "ip link" and "ip addr" to paste.debian.net. <tsmish>dajole: can also try to use networkmanager to try bringing it up using nmtui. <dajole>yeah, it does say no carrier. nmtui gives the same message. <dajole>I have already double-checked them, but maybe they are flaky. Let me check once more <dajole>I tried a different cable and now it works. Thank you so much! I thought that maybe I had missed something in the software setup. <Jaeme>On GuixSD, how do you get flatpak applications desktop entries to show up? <tsmish>Jaeme: Add /var/lib/flatpak/exports/share and ~/.local/share/flatpak/exports/share to XDG_DATA_DIRS I guess, don't have guix system here, check that paths (/var one at least) exist. <Jaeme>I did try that, but it gets overwritten for some reason after reboot <Jaeme>I think there ought to be a Flatpak guix home service. <tsmish>Jaeme: does GuixSD have profile.d, my debian has a script called /etc/profile.d/flatpak.sh that writes XDG_DATA_DIRS. <xisop>interesting, so is flatpak an application framework that you build within? <xisop>oh, so it's almost conceptually like running a vm <Jaeme>xisop: More like containers. <Jaeme>Guix is a more elegant solution to flatpaks. <Jaeme>But the apps I need don't have a build definition yet in Guix. <Jaeme>The flatpak build definition doesn't export the necessary directories to XDG_DATA_DIRS. I wonder if it should. <xisop>oh, for some reason I thought guix was a distro <tsmish>xisop: they (flatpaked apps) work like your typical apps. You just click twice on firefox icon and firefox starts up. They do a bunch of stuff that makes sandboxing more or less transparent like portals (example: you click select file in app, a file selection dialog pops up, you select file and it does magic to put it in container). <Jaeme>xisop: No problem, GuixSD is the distribution, similar in vein to NixOS. Guix itself is a package manager. <tsmish>Achually, GuixSD got renamed to Guix System (i think) a while ago. Still think previous name was better. <Jaeme>tsmish: Nice catch thanks, yeah I prefer GuixSD, but Guix System seems simpler. <xisop>heh, you have to run the binary installation as root, but i definitely am looking forward to using guix as a non-root user <tsmish>xisop: check your distro's repos, could be in them. It autoupdates on guix pull anyway. <xisop>yeah, i saw that part about guix pull.. which is awesome. i barely need the latest <xisop>erm, the guix binary, to be specific <euouae>how can I have a wayland gdm+gnome on guix? <euouae>I'm getting gdm-service-type is unbound <tsmish>xisop: I remember somebody telling me that guix doesn't work on MacOS. <xisop>tsmish: ah, no worries. i can just run the qemu img <Jaeme>tsmish, xisop: I'm planning to get a Asahi Fedora Remix liberated M1 soon, Guix shouldn't have a reason *not* to work. <tsmish>euouae: gdm-service-type is defined in (gnu services xorg). You need to use-modules it. <Jaeme>tsmish: All Apple silicon machines are fully conformant to ARM, it's the evil sounding "neural engine" that the Asahi hackers can't use. <euouae>tsmish, okay so I need (gnu services xorg) for wayland? <euouae>I'm just trying to make sure I got this right <tsmish>euouae: Yeah, a bit counterintuitive I agree. <euouae>now I get the error that xorg-server is provided more than once <euouae>(use-modules (gnu) (gnu services xorg)) (use-service-modules desktop) (use-package-modules screen certs) <tsmish>euouae: Can you post your config on paste.debian.net? That looks like an error is services field of operating-system. <tsmish>euouae: that's because %desktop-services already includes gdm-service-type. I'll give you a fixed version a bit later. <euouae>nvm I see what I hav eto do tsmish, I need to use modify-services <tsmish>euouae: Yeah, that was what I was trying to do. <euouae>there was an example like that on the manual so I copied it <euouae>tsmish, I also had a lot of trouble with encryption to the point where I completely disabled it <euouae>have you managed to have an encrypted disk? <euouae>I couldn't get it right. I'm not sure, is luks2 supported? I know that only pbkdf2 is supported but I thought I could get away with luks2 <tsmish>euouae: I am not on Guix System. Back when I was I was booting from lvm (I added support for it in guix). <euouae>lvm with or withoutr encryption? <tsmish>euouae: without, but luks2 should be similar. Looking at docs the most significant problem seems to be grub not understanding luks by default, which is where kernel and initrd is. <euouae>ah so grub needs to be configured in config.scm to understand luks? <tsmish>root-on-lvm had similar problems. That's the reason it wasn't implemented by me. I just patched gnu/bootloader/grub to add insmod lvm, but there should be a proper solution now. And I think root on LUKS is described in documentation. <euouae>Perhaps it is, I haven't found it <euouae>the unfortunate thing about gnu docs is that they tend to be fragmented <euouae>and while I can usually put the pieces together, when it comes to bootloaders and such low-level stuff, I'm a bit lost <euouae>and when I search for luks in the guix manual, I don't see anything I haven't already read <euouae>yes, doesn't work for some reason I'm dropped to grub rescue <euouae>note that I'm saying the docs are fragmented -- even though this is a complete config.scm it doesn't tell you how to do the partitioning etc <euouae>the early steps are not very well documented anywhere and finicky too -- and guix on top is unique in how it does things <tsmish>euouae: ok, before I'll go looking at bootloader configuration generation. Can you open grub.cfg and tell me if you see "insmod luks"? <euouae>right now I've given up encryption tsmish, but I think when I saw the grub.cfg I noticed it did a `search ...` with the UUID of the ext4 inside the encrypted part <euouae>and that was done pretty early, I think grub did not bother unlocking anything <tsmish>euouae: eh, alright. There is kind of a problem with guix not having facilities to copy kernel and initrd to /boot which is a origin of these kind of issues. <euouae>I really wish someone would put a guide together to kexec into guix <euouae>it would be nice to have the entire disk encrypted with guix in it and just boot from a usb <euouae>then luks2 + argon2 can be supported <tsmish>euouae: Guix is also well, for "power users". Things kinda break here and there and you are sometimes forced to look at source code to see when you went wrong. <euouae>I'm a power user, but like I said, the early stuff is not my thing <euouae>it's not like reading grub2 source code is easy <euouae>my plan is to start using guix unencrypted until I can figure out how to either kexec or set it up with luks(1? 2?) and pbkdf2 <tsmish>euouae: I mean adding "insmod luks" "insmod luks2" to grub.cfg immediately after the comment to not touch anything should have wprked. Familiarising yourself with grub command line, wouldn't hurt either. It's a bit annoying, but it's not very complicated. <tsmish>saying as a guy that rebooted into grub rescue like 20 times a day <tsmish>euouae: there are also system tests somewhere, let's see if I can find them. <euouae>tsmish, I tried understanding grub rescue but even the commands I saw online would say "not found" <euouae>and so I was completely lost at that point <euouae>e.g. `boot` says not found. `lsmod` says not found, etc <tsmish>unless they broke and no one run them (wouldn't be surprised) that should work. You can try running them yourself by running "make check-system" in guix monorepo, but prepare to suffer. <xisop>i'm really liking guix so far <tsmish>euouae: strange, haven't worked with grub that closely for a while, but lsmod should be present even if all modules failed to load. That said grub commandline without modules is very bare-bones, maybe I'm wrong. I think help displays all active commands, but I could be wrong. <euouae>I looked up the commands online, most of them were not found on the grub rescue <euouae>and I tried hard to figure out why, and someone explained it online, but I didn't understand the explanation. It's all a mess, the early boot stuff <tsmish>I do remember being listing files on disks by pressing tab, because there was no ls. <euouae>I've read the grub manual, it's a mess too <xisop>guix shell! holy crap this is amazing <xisop>that could potentially be nice to automate a temporary environment and then purge it once done <tsmish>euouae: if you want pointers I highly suggest you look at that system test and try running it. <tsmish>if it fails you have a nice bug report reason on your hands <euouae>what does it mean to run that systme test? <apoorv569>Is it possible to build LXC images using a minimal Guix system config? <tsmish>euouae: You'll need to clone guix monorepo from https://git.savannah.gnu.org/git/guix.git. run 'guix shell -D guix' or 'guix shell -m ./manifest.scm' in order to get required build dependencies. Then run 'make check-system TESTS=encrypted-root-os' to run the test. <euouae>and so I run this test after what step? <tsmish>It will create a VM, so you should have some ram available <euouae>oh so I can run this test without setting up anything? <tsmish>euouae: yeah, it will create a vm, perform an install and I think boot into installed system. <tsmish>apoorv569: I think guix system container can build a variety of images including Docker and OCI. <apoorv569>I don't see LXC here in this list, guix system container --list-image-types <the_tubular>Well I meant Docker Image and an OCI Compliant Image <tsmish>the_tubular: no idea, I thought docker had their own format before OCI appeared, then there was two different formats. <tsmish>apoorv569: I haven't worked with lxc (or docker really), but Internet says lxc create can import docker images. <apoorv569>tsmish: I see. Thanks. `lxc create` might come in handy. <euouae>tsmish: I tried the make command and I got a build error because of lack of free disk space <euouae>module-import-compiled.drv failed <tsmish>euouae: I guess try "df -h" and see what disk got eaten. I think it works in /gnu/store. <tsmish>euouae: "guix gc" will probably help, if it is disk with /gnu/store. <euouae>I don't see anything in bad shape <euouae>also -- dang, there's a /run/systemd? I thought I ran shepherd <euouae>oh well, I tried. tsmish, as you see, it's a mountain of errors, one on top of the other, leading to cascading X-Y problems <euouae>now I need to debug the makefile or something <tsmish>euouae: /run/systemd is probably some compatibility thing from elogind. <euouae>7.5G of compatibility is kind of expensive compatibility <euouae>I'm thinking that maybe tmpfs ran out? It did mention this line: <tsmish>euouae: you aren't putting 7.5G in /run, considering /run is stored completely in ram. It's probably a bind mount destination. <euouae>guix system: warning: at least 1526.3 MB needed but only 1408.4 MB available in /mnt <euouae>and tmpfs is 1.5G according to df -h <tsmish>euouae: can you paste logs somewhere (paste.debian.net, but I see folks preferring other destinations). <tsmish>euouae: could be, doubt it is in /run though. <euouae>I can paste in paste.debian.net. Let me re-try the make command capturing all output <tsmish>euouae: Oh, you know what, I think all builds happen in /tmp before getting copied to /gnu/store. You can probably try bind-mounting /var/tmp to /tmp and trying again. <tsmish>euouae: or just stopping tmpfs mount. I thought 'unshare -m' could help, but builds are done by guix-daemon which wouldn't be affected by it. <euouae>I'm trying your first suggestion <tsmish>euouae: wait, stop, it actually complains about that the disk in the vm is too small. tmpfs could be completely unrelated. <euouae>so... that means they messed up the makefile? <tsmish>euouae: that's not actually in makefile, most stuff happens in etc/system-tests.scm and gnu/tests.scm. It's probably just guix getting bigger and noone running system tests, because they are a pain. <euouae>fair enough. at least we discovered something <tsmish>we've got guix pull breaking like 2 days ago because nobody bothered to run 'make' <tsmish>I don't think guix has a CI system. There is hydra, but I think it doesn't run tests. <euouae>you seem to know a lot about guix, how are you involved? <tsmish>euouae: don't ask me, I arrived here like 4 days ago to ask questions about cargo-build-system. <euouae>wait, you patched guix's lvm thing though? <tsmish>euouae: Yeah, but that was like 3 years ago. <euouae>tsmish, I wanted to get involved with guix because it seems that it is great for developers, do you agree? <euouae>I use debian now but it's annoying having to re-install software whenever debian breaks something. Reproducible builds are nice obviously <tsmish>euouae: I ran guix system for a while and there was a bunch of problems I had to solve, so I guess I learned a decent bit about the system. Also I run stuff people ask me about, so I may appear more knowledgeable than I am. I also know a lot about linux from running it for a long time and a lot of that knowledge is applicable to guix. <euouae>(breaks something with respect to me trying to build some software & the dependencies are broken, etc) <tsmish>nice thing about guix is the ability to patch things. Doing this in debian for example and packaging it is much harder. Also packaging in general is simpler. There is "guix shell -C", which is probably the best sandboxing thing around. A lot of earlier problems have been worked out too (hey, they finally did WineOnWine64). <euouae>I see what's happening, the run-install command is using 2200 MiB of RAM <euouae>I could probably tweak it a bit and get the necessary memory I need <euouae>Yes I've tried the patching tsmish and it is super simple <euouae>I patched e.g. GNU hello to add an -x option <euouae>and the patching is super attractive to me because I can test some stuff. <tsmish>euouae: I mean I found it, go to gnu/tests/install.scm, find %encrypted-root-installation-script and add a bit of memory to 1.6G second partition <euouae>oh that's where it was? I thought it was somewhere else. <tsmish>run-install defines 2200MB memory for an entire disk, so there should be enough space <euouae>some other tests run with more memory <euouae>what's the point of that variable memory thing, just have all tests run with 9GB or whatever <tsmish>"least 1526.3 MB needed but only 1408.4 MB available" you need like 200 megs extra. <tsmish>euouae: all tests run with 2200MB of memory (see run-install in the same file), it's just the partitioning in case somebody wants to test raids and stuff. <tsmish>At least I think they do based on a cursory glance. <euouae>searching for MiB it looked to me like some things use more memory <euouae>there's all sorts of (* magic-number MiB) in that source code <tsmish>oh, true. I mean running all of the tests will theoretically consume sum of all these sizes, so it makes sense to decrease required disk space. <euouae>aren't these tests run sequentially? <tsmish>yeah, but /gnu/store is not cleared until gc <tsmish>euouae: each disk is unique, so it gets stored as a separate item <euouae>but I still got that warning about less space in /mnt <tsmish>euouae: did you increase the space in parted command? <euouae>and it seemed to make progress this time; but it still errored out around the part where the 1526.3MB / 1408.4MB thing was mentioned <euouae>same thing, module-import-compiled.drv and installation.drv <tsmish>euouae: can you commit your changes? It did finish surprisingly fast, so maybe it didn't get updated. <euouae>commit the changes to the git repo? <tsmish>euouae: You see installation script output in make output, does parted command say 1.9G? <tsmish>euouae: it is a little after all the shepherd stuff and dmesg output. <euouae>let me run it again, screen overwrites the dang output <euouae>so I have to run it again and save it <euouae>everything is against the user on linux land <euouae>a lot of this nonsense is because we need to support AIX or something. <tsmish>euouae: etc/system-tests.scm does some things with git, so I suppose making a commit could help. <tsmish>euouae: tmux supports scrolling if you are using raw console. <tsmish>there was scroll lock, but that got removed <euouae>I'm not using raw console I'm on gnome now <euouae>I think some screen config allows you to have more output, I just forgot to include it <tsmish>euouae: no, there is no git hooks. Just check that installation script in make output is wrong and then we can go from there. <tsmish>I mean, look at etc/system-tests.scm, I think it does funny things, or you edited a wrong script, <euouae>I edited gnu/tests/install.scm line 752 <tsmish>euouae: Yeah, that should be the one <euouae>and yeah I don't know how you figured out that etc/system-tests.scm is responsible, but it is <euouae>maybe the idea is some kind of thing about reproducibility or provenance <euouae>of course there is no documentation about WHY it does such weird things <tsmish>euouae: look in Makefile at check-system <euouae>yeah I see it is running system-tests.scm but I would not have thought of looking inside that file <euouae>it wouldn'thad occurred to me that such strange things are happening in it <tsmish>euouae: listen, writing documentation is hard. <tsmish>I only found out about system-tests because civodul told me <euouae>If I can get certain things working I'll try to contribute them to guix <euouae>but it's not just docs are hard, sometimes they're just bad <euouae>I wont' say this for gnu guix, because it's a new-ish and very ambitious project <euouae>but for example gnu grub has terrible documentation <euouae>maybe that's what I should do, fix the grub documentation. <euouae>I committed; the parted script still uses 1.6G <euouae>Either we have the wrong line or something else is going on <tsmish>euouae: You are running encrypted-root-os? <euouae>I'll sed all the 1.6G's to 1.9G's and see what happens <tsmish>euouae: I'm running out of ideas: make clean? <tsmish>although it gets recompiled, so that probably won't work <euouae>if make clean solves this, then something really weird is happening <euouae>like wrong dependencies in the makefile <euouae>let's see first if the in-place sed solves this <xisop>Greetings. I'm using the qemu image. do i need to pass anything special to qemu if i want my changes to persist? <tsmish>euouae: we can also try good old print debugging <xisop>tsmish: heh, i do that all the time :) <xisop>i guess i could find out by rebooting it eh <euouae>qemu has clones that may interest you <euouae>so you can have a base.img and a clone.img -- changes in clone can be reverted by booting from base.img <xisop>interesting. that would be super helpful <euouae>qemu-img create -F qcow2 -f qcow2 base.img clone.img <euouae>Don't boot base.img before deleting clone.img, it could leave clone.img in an unusable state <euouae>you can make clones of clones, but you can only boot the leaves of the tree hierarchy of cloning <euouae>or at least I think that's how it works <tsmish>euouae: Don't you need -b for setting up BACKING_FILE. I used this when I needed to give a users a VM they could make temporary changes in that would get removed on logout. <euouae>I'm going off memory because my notes are in my debian installation and I'm messing around with guix now <euouae>I really need to get a secon computer <euouae>tsmish, something weird is happening <euouae>I replaced all 1.6G occurrences with 1.9G and committed but I still get 1.6G to show up in logs <tsmish>euouae: you do git add before you commit? <euouae>my branch is 2 commits ahead of master? <tsmish>My other guess is guix not tracking an input and mistakenly getting an old copy. guix gc should help if that's what happening. <euouae>it is actually a dependency bug in the makefile <euouae>it's not that these bugs are simple or anything like that, I'm not demeaning the guix projec <euouae>but I started with a "can't figure out encryption" problem to land to this... :( <euouae>it's like I'm cursed, this always happens <euouae>I ran `guix gc` and then `make clean`. Let's see now. <xisop>what does this usually mean? "To enable SSH inside a VM you need to add an SSH server like openssh-service-type to your VM (see openssh-service-type)." <euouae>xisop, you need to change /etc/config.scm to tell it to install openssh <tsmish>euouae: well, if that fails time to place a lot of display statements all over %test-encrypted-root-os. Which we should have probably done initially to check if our changes are getting picked up. <xisop>what is usually the process for getting newer versions of packages? <tsmish>xisop: guix pull; guix package -u? <euouae>then you can do `guix upgrade` which is `guix package -u` <euouae>guix pull basically updates your `guix` and the package list selection <euouae>by `guix` I mean the guix command-line binary <apoorv569>What are `specifications`? Like there is this `specifications->manifest` or `specification->package+output` etc? <euouae>a specification is a textual description of a package <efraim>I normally use it as (specification->package "hello") <efraim>or (specification->package+output "git:send-email") <euouae>a specification specifies by means of text <apoorv569>So `(define-public ` block is a specification? <euouae>even after `guix gc` and `make clean` <tsmish>euouae: you can try breaking %test-encrypted-root-os by say replacing run-basic-test with nonexisting-run-basic-test and see if it breaks. <euouae>it looks like it's not getting picked up <euouae>I'm doing this under `guix shell -D guix git` <tsmish>ok, that's weird, because it works for me <tsmish>I can't actually run tests because I get "Could not access KVM kernel module: Permission denied", but things do break when I break them <euouae>but you're not on guix systme right? <tsmish>eh, maybe look at it afterwards, you were trying to do this for like 5 hours <bdunahu>Hi, does anyone here use mpv? I had a suspicion that a lot of issues I was encountering when trying out a full guix system related to my initial window manager choice in the installer. I have switched to GNOME. mpv will still not play a video--it segfaults and does not leave behind very useful debugging information in the logs, though it can play audio files. Does anyone have a solution for this, or an idea to troubleshoot it? Possibly <bdunahu>how to search for older versions which are available to be tested? <euouae>A breaks, and 20 letters later I'm trying to fix S issue <euouae>bdunahu, do you run mpv with verbose output? <bdunahu>I used the debug level output: mpv--msg-level=all=debug <tsmish>bdunahu: you can try running in under gdb and enter bt when it crashes, should at least give you a library. <bdunahu>no error messages, I will attempt the gdb idea <tsmish>bdunahu: Are you on Guix System? <euouae>What you typically do in these situations is generate a core dump and then inspect it with gdb but I don't know how to do that on guix <euouae>perhaps `gdb ./myprogram` and then `run` and once it segfaults you can do `gcore` but I'm not sure <tsmish>I had a weird crash because (I assume) vapoursynth was compiled against guix python, but got linked with debian python. <euouae>tsmish, well if I delete the file it gets picked up as an error <tsmish>euouae: I suggest you go chill and stop banging your head against it. Solution will come to you eventually. <tsmish>And it is going to something very dumb <bdunahu>I am not really sure how to use gdb in this way, I have only ever used it on my own programs. Can you be more specific as to how you would use it here tsmish ? <tsmish>bdunahu: should give you a library name. I actually don't know how to bring debug symbols, so the library is the only thing you'll get. <euouae>It's documented in chapter 17 of the info manual of guix <euouae>and you can build mpv with debug info if it is missing <euouae>see tsmish? I know some stuff :P but nothing that is related to early boot. I suck at that. <bdunahu>package mpv@0.37.0 lacks output debug <bdunahu>I'll have to read this section of the manual some more, but I am not sure if this is possible <tsmish>bdunahu: Are you on guix system? <tsmish>bdunahu: does it still crash with --no-video? <bdunahu>no, I was also able to play audio files fine <tsmish>oh... look towards video drivers and mesa <tsmish>they are basically shared libraries and they can crash the parent process <tsmish>bdunahu: can you play videos with --vo=sdl or even simpler outputs? <bdunahu>Hmm, okay. I have a feeling some other issues I've encountered are probably related... I switched from exwm to the gnome environment to try and troubleshoot emacs 29.1 transparency not working. It still didn't work in gnome <bdunahu>specifying x11 works, not sure if I have the other driver you mentioned <tsmish>yep, definetly video driver/mesa problem <bdunahu>Okay, thank you! I'll start looking into that <tsmish>I guess you could try installing mesa and see if that solves your problem. There is also stuff in mesa-utils that can crash too. <tsmish>bdunahu: I think mesa implements all of user space drivers by itself for amd and intel. <adanska>Hi Guix! I'm trying to set up the new `home-pipewire-service` on my machine, but when I try to configure it I get the following message: `guix home: error: service 'pipewire' requires 'dbus', which is not provided by any service`. Has anyone else come across this? <tsmish>adanska: can you add (service home-dbus-service-type) to your home configuration and see if it fixes it? <adanska>it seems to be working now. Thank you! <bdunahu>simply installing the mesa drivers/utils and rebooting did not fix the issue. --vo=sdl is not an option displayed in --vo=help <efraim>I heard today to try out --vo=gpu-safe, never tried it though <bdunahu>whatever it is it doesn't seem to exist on my system either <tsmish>bdunahu: might also be something in dmesg <apoorv569>`(groups` and `(users` are not necessary in `guix system containers` right? <apoorv569>in config for `guix system containers` I meant. <jpoiret>bdunahu: usually you don't want to install mesa but rather libva and libvdpau depending on your system (you can install both) <jpoiret>but not having them shouldn't segfault <jpoiret>hm, it's not yet about hw decoding, my bad <jpoiret>mothacehe: thanks for the quick reviews :p <rekado>hmm, someone broke the CRAN importer’s “--style=specification” option <rekado>it’s been removed and only the parameter was left behind <rekado>found the commit: e6223017d95bc615b2648f0798d9a3904d5b5f57 <rekado>(fixed in fda9a6d25c8457b3db165210d59a527290a59a6d) <bdunahu>jpoiret: thanks, I will have to look at it again later. I do at least understand the issue a little better <rekado>what’s up with the workers at ci.guix.gnu.org? <rekado>yet we’ve got the r-updates branch waiting to be built <lilyp>don't forget three runs of webkit for gnome-team… <jpoiret>lilyp: is there a rough ETA for gnome-team? i'm interested in the libgudev update for iio-sensor-proxy <lilyp>there's a hand full of issues open, but atm no meta issue capturing our status <lilyp>I should probably write a script to compare Guix versions vs. gnome releases <efraim>i wonder if repology has something already setup <tex_milan>Hello, I am on GuixOS, non-free Linux kernel, I want to use USB DVB-T2 stick (Evolveo). When I plug it, it doesn't trigger any messages in dmesg, it is not visible in lsusb. Any idea what is going on? The stick works in Windows and in other Linuxes (on different PC). <lilyp>Sorry, but we can't really help you debug nonfree software :) <rekado>the build farm is processing builds, but the throughput looks wrong to me <lilyp>Sadly no, it only looks at the name and the tags aren't that good <efraim>you can cancel all the rust-team builds if there are any. There aren't supposed to be any ATM <lilyp>I think we can also drop wip-webkit <lilyp>both from CI and the repo itself <jpoiret>hoho, GRUB 2.12 was released in time for christmas! <lilyp>a build that is waiting to be built <elevenkb>lilyp: thanks. it's wild that they are increasing though... isn't it? <lilyp>it means the builders aren't building <rekado>I’m tailing /var/log/cuirass-remote-server.log on ci.guix.gnu.org and stuff is happening <rekado>builds get started, builds succeed <rekado>I wonder if perhaps the builders should all have their cuirass-remote-worker service restarted <rekado>ACTION just restarted the worker service on a bunch of nodes <PotentialUser-76>Alternately, see `guix package --search-paths -p "/root/.config/guix/current"'. <PotentialUser-76>hint: After setting `PATH', run `hash guix' to make sure your shell refers to `/root/.config/guix/current/bin/guix'. <gabber>PotentialUser-76: it seems you haven't followed the mentioned instructions ;) <gabber>does grub expect a specific kernel image format? i ran into an "error: invalid magic number" -> might that be because the Image in place was compressed? <PotentialUser-76>efraim if yes, no error occurs : [root@+++oia:~]# GUIX_PROFILE="/root/.config/guix/current" <gabber>PotentialUser-76: the /root/ part seems as if the GUIX_PROFILE variable was configured to make use of the root user's guix checkout/profile <gabber>what exact command led you to that guix output message you posted earlier? <PotentialUser-76>I'll be glad to launch apps installed via guix from terminal ; gabber sudo -i guix pull <gabber>you usually don't need sudo for guix pull <gabber>you can $(guix pull) from your user and only need sudo for system reconfiguration i.e. $(sudo guix system reconfigure config.scm) <gabber>sudo is only necessary for special operations -- like directly writing to devices, un- or remounting stuff, etc. the usual Guix business can all be done from user-space <gabber>also, when using sudo (for whatever reason) in context of Guix, omit the -i flag <gabber>PotentialUser-76: ah yes, you are right. but only for upgrading the build daemon. IIUC you can then safely ignore those messages you posted earlier <PotentialUser-76>i'm testing out a little bit w guix still, intending to move to a full system install – <gabber>would you mind pasting the error to a paste-board and post the link here? <rekado>I think there are network problems at the MDC data centre. Trying to get someone to look at it. <gabber>PotentialUser-76: you could run: $(guix build emacs)/bin/emacs to run a Guix version of emacs or you can install a package to your profile with $(guix install emacs) and then run $(emacs) -- this *should* point to the correct binary <gabber>or you configure guix home, containing all the packages you want to use -- our declarative way of per-user package and configuration management <PotentialUser-76>emacs-guix 0.5.2-7.455272c out /gnu/store/mgnfsrsixm5fh4dfqdlcw0lsfcyb87mp-emacs-guix-0.5.2-7.455272c <PotentialUser-76>texlive-hyperref 66594 out /gnu/store/shjyckag7fv2bday4ifjw94drl4vm1n3-texlive-hyperref-66594 <PotentialUser-76>tectonic 0.12.0 out /gnu/store/jrdac89viqpbx25ihvl31pz7fjf68j07-tectonic-0.12.0 <PotentialUser-76>emacs-auctex 13.2.2 out /gnu/store/3r0s39jfj07zwp8d51jg27mcfax0fchs-emacs-auctex-13.2.2 <PotentialUser-76>emacs-company-auctex 0.1-1.48c42c5 out /gnu/store/7wfla1q56sih89adzdbxgqldy2dciv4a-emacs-company-auctex-0.1-1.48c42c5 <PotentialUser-76>emacs-next 30.0.50-1.9d27b95 out /gnu/store/a6528ydcw2prdhap7w1gjd70ib5ffjc3-emacs-next-30.0.50-1.9d27b95 <gabber>please don't paste multiple lines in here <elevenkb>Is there any way I can access the transform-package-tests function in (guix transformations) by force? <elevenkb>I just copy pasted it into my module, which isn't a good idea but otoh forcing a package to build without tests isn't a good idea either. <lilyp>options->transformations is your friend <rekado>ci.guix.gnu.org may become unavailable for a little while <mirai>Where should I insert 'gpgconf --create-socketdir' in order for it to execute upon my login? <mirai>mostly relevant when login is via ssh <ssouth>mirai: I think you're looking for either ~/.ssh/rc or ~/.profile (or ~/.bash_profile). <ssouth>The man pages for ssh and bash have the details. <dthompson>did a world rebuild accidentally get introduced recently? I updated my local guix checkout to finish up a patch and when I try to build I'm seeing a giant list that looks like a world rebuild to me. <mirai>dthompson: do a make clean-go <mirai>there was some change that triggered this although it wasn't a world rebuild <dthompson>thanks. will report back after the long wait to rebuild. <rekado>dthompson: rm gnu/packages/bootstrap.go <dthompson>rekado: ah thanks, unfortunately I'm already in a full rebuild 🙃 <rekado>ah, okay. I misread that and thought you’d wait for a world rebuild :) <rekado>FYI: 10G switch for ci.guix.gnu.org is now being swapped for a new one <jpoiret>TIL about the -v 1 option for guix build which shows what is being built but not the build log <jpoiret>very nice in emacs when it would just keep filling up the shell buffer otherwise <gabber>apoorv569: in the context of a "world rebuild"? <jpoiret>world rebuild means that almost all packages need to be rebuilt <jpoiret>when eg. a very low level dependency changed <gabber>how come the kernel i use in a package config needs derivations built when used in an operating-system configuration? i build it first manually just for it to be rebuilt completely (?) when i create a system image? <jpoiret>apoorv569: it's not specific to a single distribution I htink <apoorv569>About the kernel, I'm curious if its possible to customize the kernel declaratively or via providing a kernel config file? <gabber>nvm: i guess i did some (minor) change to the package definition (or did i?) <jpoiret>apoorv569: you can provide a config file or a defconfig file <apoorv569>I am assuming for customizing packages we have to basically create our own inheriting from the base. <apoorv569>Where do we pass the config as arg? What's a defconfig BTW? <jpoiret>see customize-linux in (gnu packages linux) <jpoiret>wrt. defconfig, they're basically override files for config options <apoorv569>jpoiret: Like the config.def that suckless tools use? <apoorv569>Found the customize-linux.. interesting stuff. <mirai>how can I add a simple 'gpgconf --create-socketdir' to my bashrc that's managed by guix home? <apoorv569>ieure: I changed my GNUPGHOME to be under ~/.local/share/gnupg instead, can this home service read that automatically? <mirai>and the socket directory doesn't exist when logging via ssh as /var/log/messages shows me <mirai>localhost sshd[1194]: error: unix_listener: cannot bind to path /run/user/1000/gnupg/S.gpg-agent: No such file or directory <ieure>apoorv569, Not sure, probably depends on whether you set the environment variable before the service starts or after. <ieure>mirai, Ah, so this is a thing you need on the *remote* host (which may not be running Guix/SD). <mirai>the remote is Guix inn this case <mirai>yeah, and ~/.ssh/rc is out of question as it doesn't have any awareness of where gpgconf is <apoorv569>ieure: So I need to set env vars using home config as well (which I should move to anyway), but we can set order of stuff in the config can we? <ieure>apoorv569, Yeah, far as I know, it runs stuff in the order you put it in the home config. <ieure>mirai, One sec, I think I have some code you can adapt. <apoorv569>I see. Then I should be able to just put the env vars before I define the gpg home service. <ieure>You'll want to remove the (requirement '(x11-display)) -- that makes it only trigger when you log into a graphical session. <ieure>And to actually add it to your home config, you need: (service home-jellyfin-mpv-shim-service-type #t) <ieure>It seems that services have to have arguments, but this one doesn't need anything, so #t is the argument, and it gets ignored. <mirai>ieure: it won't do with shepherd I'm afraid <mirai>I've just tried using home-run-on-first-login-service-type and although the directory does get created, it is too late <mirai>as the logs complain of the missing directory <mirai>looks like it has to be executed before the login shell rc is finished running <ieure>mirai, Okay, you're going to have to put the command you need in a shell script, then use customize home-bash-service-type to include that in the list of bashrc files. <mirai>won't it require an absolute path for the gpgconf though? <ieure>I don't understand that question. <ieure>Does `gpgconf --create-socketdir' need an absolute path? <mirai>I guess bash will know what packages are available in its environment <mirai>it's that simply pasting `gpgconf --create-socketdir' to .ssh/rc would result in sshd not finding where gpgconf is <ieure>Oh, I understand now. Yeah, as long as it's on $PATH, you're good. <mirai>so I assumed the same would happen <rekado>all three switches have been replaced; restarted all the cuirass workers. <zilti>I have a program here (chicken scheme) that relies on environment variables to find its extensions - which works fine if I install the extensions via home-configuration.scm (or config.scm). But I'd like to use guix shell with extensions. Now I need some way to figure out where "guix shell" links the extensions to. There seems to be nothing in the env vars that tells me this. Is there a fixed "virtual" directory for that kind of stuff, o <zilti>r a command I can run that returns the place? <ieure>zilti, `guix build some-package-name' will print its store path. <ieure>zilti, You might want to look into how Python handles this. IIRC, it creates a derivation in the store which is full of symlinks to the specific libraries installed. Sounds like a similar approach might work for your usecase. <dariqq>zilti: afaik it should work if you create a shell with both the programm and its extensions. <Kabouik>Does anyone know how to use nbfc-linux on Guix? It's packaged but I cannot find how to use it, and sadly florhizome who packaged it doesn't seem to have been online in the last months. <Kabouik>I need to use a custom configuration for it, but when I try to run it in CLI it seems to require using something in its /etc json only. And then even when I manage to use my own config, I don't know how to set it up as a service. <dariqq>zilti: just tested this with guix shell python python-numpy : numpy is available via python env var. if python is in main profile and i just do a guix shell python-numpy the guix_pythonpath env var will not get created/updated. <dariqq>so probably you can do something similiar for chicken <zilti>dariqq: Thank you, I will try this! <freakingpenguin>Hey all. Does Guix have an easy way to take an existing service and make it not auto-start on boot? I have a (service wireguard-service-type ...) in my system config that I only want to start manually. I see there is auto-start? in shepherd-service, but it seems that requires creating an entirely new service and would be pretty complicated. <ssouth>freakingpenguin: If no one else answers you: There wasn't last time I checked, but it's not hard to implement that functionality. <ssouth>Then in (services) you simply wrap the service type, like "(service (auto-start-disabled knot-resolver-service-type))". <ssouth>Note I am not a Scheme expert; improvements to the code welcome. <rekado>unfortunately, the build farm still isn’t working enough <rekado>it’s processing builds, but only very few at a time <rekado>doesn’t seem to be a network problem. <rekado>the workers keep asking for builds (“request work”) but the logs say “no available builds” <zilti>dariqq, ieure: thank you, it worked when additionally including the base package :) <rekado>any ideas how to debug the cuirass queue? <jmml>i'm updaing the fennel package but "guix build fennel" fails during the "make test" phase. since the same failure affects the current package am i right that it's ok to send a patch that just updates the version and hash? there is a patch available upstream already so including it is no problem just not sure what is preferred. <ssouth>jmml: Are you saying neither the current version of the package nor your updated version builds for you? I.e. the "check" phase errors out in both cases? <jmml>well if i run "./pre-inst-env guix build fennel" on the current version it doesn't appear to run the "check" phase so it doesn't error. after updating the version and re-running "./pre-inst-env..." it does the "check" phase and errors. <jmml>i checked the 1.3.1 tarball and the error happens there. is there a way to force build to run the check phase on the current version? <ssouth>jmml: I see from the package definition (in gnu/packages/lua.scm) that tests are enabled, so the "check" phase should be running. You can verify this by checking the build log. <ssouth>I.e. "guix build --log-file fennel", which will give you the path to the build log (or perhaps a link to the log file online). <ssouth>It sounds as though the test suite is passing on the current version of the package, but failing on your updated version. That would be a regression so you'll need to fix that before submitting your changes. <jmml>the only line in the log file is "grafting '/gnu/store/q4skgvf171slnjyy216jnfbn5a2lwcpd-fennel-1.3.1' -> '/gnu/store/hjqz68kbv1icvhnndl9pachdfln6v6pl-fennel-1.3.1'..." <ssouth>Ah. In that case get the log file of the ungrafted package: guix build --log-file /gnu/store/q4skgvf171slnjyy216jnfbn5a2lwcpd-fennel-1.3.1 <ssouth>Hmm. That is not what I expected. <jpoiret>ssouth, jmml: you can use --no-grafts to disable building the grafting derivation <jpoiret>you often just want to try rebuilding using `guix build --check --no-grafts fennel` <jmml>jpoiret: thanks that did it and no errors in "make test" there... <jpoiret>the_tubular: you get the `guix` package in your profile. it always refers to some fixed older commit, and will probably mess with your `guix pull`d guix <jpoiret>jmml: then it's probably your update that's breaking the tests <ssouth>jpoiret: Thanks, that's what I was looking for just now ("--check --no-grafts"). <the_tubular>But isn't guix suppose to be already in your profile jpoiret ? <jpoiret>the_tubular: not in ~/.guix-profile, but in ~/.config/guix/current. The former is your `guix package` profile, while the latter is the one where `guix pull` installs guix + channels <jpoiret>since ~/.config/guix/current is still a guix profile, you can have a look inside with eg. `guix package -p ~/.config/guix/current -I` <jpoiret>jmml: no release contains this commit <jpoiret>unless you're building from a very recent commit directly <jmml>ok. i think i confused myself. 1.3.1 fails here for other reasons and i mixed things up. the error with PATH in "make test" was introduced after the 1.3.1 release. <jpoiret>ah yes, a test in rust 1.70 that breaks because of a misconfiguration for all rusts since 1.55 :) <xisop>greetings. does guix have a way of installing packages via source? <tsmish>xisop: "--no-substitutes" will stop guix from trying to fetch binaries. <xisop>tsmish: nice. i'll check that out <xisop>in the meantime, i'm teaching myself guile. <csantosb>I mean, when one checks the full package graph of python-numpy, that's a lot of compile from source. You need to compile the full software stack down to the bootstrap seed. Surprising. <tsmish>csantosb: I think it will still use what's already in the store, so it won't go to bootstrap seed.