IRC channel logs
2024-10-07.log
back to list of logs
<meaty>Where can I start with diagnosing why the swap defined in my config isn't appearing? <meaty>I find in my logs "unable to find swap-space signature" and then the service fails to start <meaty>And then this: Exception caught while starting swap-/swapfile: (system-error "swapon" "~S: ~A" ("/swapfile" "Invalid argument") (22)) <meaty>ok, I can get swapon --show to report something after calling "btrfs filesystem mkswapfile --size 4g --uuid clear /swapfile" and "swapon /swapfile". Will guix auto-swapon this from now on? <podiki>you had to have made the swapfile on your own, guix doesn't do that if i recall <podiki>so if that was the issue and it is created now where the config expects it, should be fine <apteryx>or maybe it's there only when there *are* new failures? <podiki>different color (yellow) when only non-new failures on the evaluations page <tacocatgirl>After running "guix gc" I have to redownload substitutes again after reconfiguring. Is this normal? I though "guix gc" was only supposed to delete unused store entries. <AwesomeAdam54321>sneek, later tell tacocatgirl: What substitutes are redownloaded? `guix gc` removes all unreferenced store entries, and from what I know the package profile generation phase isn't considered as a reference <AwesomeAdam54321>sneek, later tell tacocatgirl: Having to redownload substitutes after GCing is definitely annoying <Rutherther>sneek, later tell tacocatgirl: there is a way to prevent that by adding flags to the guix daemon. Specifically --gc-keep-outputs and --gc-keep-derivations, then even build tools will be referenced <mala>So it may be just me, but it feels like guix pull and guix upgrade has been getting much slower over the last year. Is this a known problem? If so what are the causes? <Lumie>Hmm, for me it's the other way around, it's really fast for me <skrech>futurile: Continuing what I was doing Friday --> it seems that `./pre-inst-env` script should be used WHILE one is in a guix shell with `-D guix`. This is so, because `scripts/guix` is different than what is installed as `guix` from the official intsaller. <skrech>apparently, guix installer script make `guix` point to `guix-command` package, which adds several dirs to it's load path from another "hidden" package called guix-module-union. <skrech>This explains why guix from non-shell can build packages successfulyy, and why running guix prepended by `pre-inst-env` doesn't succeeed on any command (even `pre-inst-evn guix describe` fails) when run from non-shell <futurile>skrech: ah interesting, didn't know that <jlicht>Anyone using emacs-dape to debug python programs? I'm running into some issues that may have something to do with our custom unbundling of pydevd from debugpy, but it's kind of difficult to reproduce <ekaitz>futurile: did you find anything about the RFC process? <futurile>ekaitz: I got distracted into looking at various RFC type things that people have done in other communities. <ekaitz>futurile: good, that is also interesting work <mgd>Hello. I'm trying to run factorio on guix. I have both the linux version downloaded from the website and the steam version. Because of the age of my laptop. I normally have to type the line `export MESA_GL_VERSION_OVERRIDE=4.5` before running the game. This doesn't seem to work on guix. Does anyone have any idea what to do? <sepeth>mgd: do you mind sharing any logs in paste.debian.net? You can also run it with strace and see more into what it was doing before it got stuck/failed. <sepeth>I wanted to try this game for a while now, and would like to try and see if it works on my side, but the demo is only for x86_64 Linux :( <sepeth>I am running on aarch64. Checking if Steam specify the architecture <dariqq>Hi, i am writing a service-type and one package needs to be setuid for a user that i am creating with an account extension. This does not seem to work though as I am getting a "getpw: entry not found" error. The user seems to exist when the the activation script is run. <dariqq>is there a way i can force account creations before priviledged programs are evaluated? <mgd>The main error is "Failed to create OpenGL context" <mgd>I'm looking for the logs <dariqq>weird, when I try to setgid instead i am getting warnings: failed to privilege <binary>: Success <dariqq>i am so confused. Only setuid works, only setguid fails with a warning and trying setuid+setguid aborts with an error <civodul>dariqq: uh, might be worth a bug report with a minimal test case <dariqq>Ill see if i can find a minimal reproducer and will report it later <civodul>it says “smtpctl: this program must be setgid smtpq” <dariqq>and before: warning: failed to privilege "/gnu/store/2ng9wzk5d13xcxhk7w7k5zzdm24shk91-opensmtpd-7.5.0p0/sbin/smtpctl": No such file or directory <nutcase>Hi guix. What is the reason for the icecat package being so old? Is it just because no one tried to update it, yet? Or is it not updateable, currently? <efraim>115.16.0 is a still supported ESR version of firefox/icecat, but I hope it gets rebased on 128.x soon <civodul>(just learned that “to privilege” is a verb) <efraim>gcc-mesboot1 choked on a newer version of gmp on i686-linux. I'll see between taking ekaitz's lead and actually building it before building gcc or see if there's an earlier version that works with both i686/x86_64 and riscv64 <civodul>(which is weird because i’ve know that “privileged” is a past participate for a while) <nutcase>efraim: ah, thanks. ESR is the reason. I didn't notice that. LibreWolf (thanks) works for me, when it comes to sharing screen in webrtc sessions on wayland, while IceCat doesn't. However, with LibreWolf I have some other issues and I'd like to compare, whether it is LibreWolf specific or also a Firefox / IceCat issue. <efraim>yeah, mpc choked on mpfr not actually being built, looks like pre-building it is! <efraim>I don't rememberthe last time I had to check with icecat, but I've found qutebrowser works most of the time for me, but I have a collection of dodgy old video cards that sometimes break at inconvenient times <ekaitz>efraim: mpc mpfr and those are a little weird, yeah <efraim>I didn't love having those old versions so I'm happy to work at making them newer for everyone <efraim>plus if we build it ahead of time it should speed up the actual builds of gcc <mgd>Can't find the logs for the life of me. I'll do some more digging <mgd>does guix not allow you run a binary? I'm trying to just do `./factorio` to just run the game <dthompson>mgd: that binary makes assumptions about what libraries can be found where that do not hold true on guix <mgd>That makes sense. Thanks <dthompson>you could use 'guix shell --container --emulate-fhs ...' as a way to deal with that <oriansj>for example libout; guix has the common lisp bindings to the library but not the library itself <oriansj>(that should give everyone here 70+ years of music in 80MB) <oriansj>sidplayfp ../HVSC_81-all-of-them/C64Music/MUSICIANS/A/ABS_3001/Demolix.sid -w${desired_name}.wav to convert to wav (as I haven't had time to figure out how to get mpv to recognize the library yet) <mgd>dthompson This approach seems to be better. Just need to see what else needs to be installed in the container to get the game running <dariqq>civodul: I cant seem to reproduce my setuid success from before (maybe i had the account already as i was switching between generations a lot). I don't understand why opensmtpd is working for me locally without errors. In which order are are the account-creation and privileging scripts run? <dariqq>i have reported this with a small reproducer as #73680 <civodul>that “Success” thing reminds me of another issue we had before :-) <civodul>sounds like errno isn’t properly captured or something <dariqq>when i tried again i also got "no such file or directory" instead of "success" (with the more minimal example instead of my whole system config). But i am not sure which file this is corresponding to, because the path to the binary exists <dariqq>hmm, when i run that config in a container i get "no such file or directory", when I reconfigure my system i get the "success" error. <dariqq>that config being my slightly adapted current system config <dariqq>looks like both priviledged-program-service-type and account-service-type are being reduced to an activation-service-type extension which might be problematic because we cant control the order of these scripts. (seems to be working somehow for direct activation extensions, where sometimes a user/group is needed to fix permissions) <ryan77627>Hi all, question on the bootloader rewrite issues (#72457) if Lilah or Hermann happen to be in here. I am trying my best to apply the various patches, but I am unsure what the dependency chain is for these issues (since there are multiple). I cannot apply most of the patches cleanly outsde of 69343, which everything seems to be dependent on. Is this still true or is there new issues that subsumes <dariqq>guix system extension-graph is a cool thing. I think the problem is that there is an (implicit) arrow between privileged -programs and accounts service that is not being modeled <luca>Hi, has anyone experienced swaylock not accepting their password? I am pretty sure I am typing it correctly, but it won't let me through. Seems like a guix bug since I haven't had this issue on other distros, but I can't really know for sure <Rutherther>luca: it is not accepting password because you don't have a pam rule for it. For that you will can create a screen-locker-service-type <Rutherther>the manual even has example on swaylock specifically if you search for screen-locker-service-type <Rutherther>other distros put the pam files in place (/etc/pam.d) when you do "xyz install swaylock". But that is not how guix works. If you put something to your system packages, it is only put to /run/current-system/profile. So it cannot affect what is at /etc/pam.d <weary-traveler>you know how at the top of the HTML manual there's a manual to select language, it would help if there were another to select devel vs not <luca>Also I am getting the following error and I'm not sure where it's coming from "error: service 'console-font-tty1' requires 'term-tty1', which is not provided by any service" <rekado>weary-traveler: it would be better to get a release, so that the discrepancy disappears <weary-traveler>i believe one is one the way. though it's only bring temporary relief before the versions diverge again <Rutherther>luca: term-tty should be provided by mingetty-service-type. That one should be in %base-services/%desktop-services. Do you have one of these in your services list? <luca>I thought I should delete mingetty-service-type if I want to use greetd <Rutherther>maybe it can. It also can provide term-ttyX service. But I suppose that if you omitted terminal number 1, you also have to get rid of console-font on tty1 <ryan77627>One other question from me today: I am attempting to update my system (this is the first update I am doing since the core-updates merge). I am getting a lot of propogated input mismatches. Two I've gotten so far was xdg-desktop-portal resolving newer than the prop-input in xdg-desktop-portal-gtk and ffmpeg being newer than the prop-input for mpv. Is this expected? <ryan77627>If so, I may see if work can be done to decouple these packages some. Like, does ffmpeg for mpv need to be propogated or can it just be a regular input? <ieure>luca, Don't use an encrypted root. <ieure>luca, Or use Guix as the package manager on a foreign distro. <ieure>Those are the only two workarounds at this time. <luca>When making packaging a new rust program should all dependencies be packaged? <luca>Are the definitions ordered alphabetically or something in a .scm file in the guix tree? <ieure>Sometimes, but I don't think that's a specific requirement. Since Lisp compilers generally don't support automatic forward references, things are usually closer to dependency order. <ieure>ex. deps of a package appear before the package within the same file. <oriansj>and it has to be done outside of guix and guix can break it at anytime. <luca>What are the rules around contributing new packages upstream? Should I become a maintainer? Active contributor first? Something else? <Franciman>and a contributor will merge it, after review <Franciman>side question: if you're italian, are you in guix italia? :P <luca>What about quality standards of software? For example some distros don't allow simple shell scripts as packages <luca>And no, not italian, but rather romanian <futurile>luca: dependencies are ordered alphabetically for rust-team. You should look at the rust-team branch as it will be ahead of master <luca>do you know by any chance when rust-team will be merged in master? <civodul>hmm i’m surprised ‘wip-gsl-upgrade’ doesn’t appear in this list <luca>hmmm, but CI does build and offer substitutes from that branch? <luca>I'll give this packaging thing a try tomorrow then. Hopefully I won't half to package half of crates.io to get it working :P <luca>But the rust*.scm files looked really impressive. Reminds me a lot of debian and how they also vendor a lot of crates <llano>I'm missing something simple, how do I initiate a build of a prior version of a rust package? For example, I want to build a patch bump of rust-darling-0.14, but doing a guix build always triggers rust-darling-0.20 <llano>Or is the correct way for local development to rename the version until I can submit a patch upstream? For example, should I inherit but make the package definition rust-darling-0.14.4? <llano>rather than the standard rust-darling-0.14 (excluding the .patch version) <futurile>llano: first you have to check that the version is available (it is from what I see), then you have to remember to build the "name" not the "variable name" <futurile>llano so it's probably something like: ./pre-inst-env guix build rust-darling@0.14.1 --no-substitutes --no-grafts <futurile>llano: we follow the SemVer of the Rust packages. So in this case we keep one version of rust-darling-0.14.x in the archive. So you would alter the current package to be version 0.14.4 (and change the hash), the patch you send would have that change in it. <llano>@futurile: thanks, I was missing the @version portion of my simple: guix build -L . rust-darling <llano>I'm building local right now as it looks like I'll need many many changes to build the top level package I am after <llano>all good practice for writing package definitions / inheriting <futurile>llano: yeah, don't forget about 'guix import' the crates one is recursive. <futurile>llano: you often land-up with really big trees <futurile>llano: so I do: guix shell --network --container --nesting --development nss-certs ; ./pre-inst-env guix import crate --recursive paste@1.0.13 <futurile>llano: and you can redirect the output to a file ofc <futurile>llano: sorry guix shell --network --container --nesting --development guix nss-certs <llano>Reading up on guix import now. Thanks for the tip, I'll try this out. <llano>Well this certainly made my life a lot easier <futurile>llano: easier - but not easy - you generally have to do a bit of messing about with stuff <futurile>llano: I initially did mine in separate files as you are. But found it then took me just as long to integrate them back into guix's source files <futurile>llano: so now I create a worktree for my changes, and do them directly in a checkout of the source. <llano>futurile: roger that, I'll probably follow suite after this go-round. I've never submit a patch before, and I generally feel unqualified to do so, but I'm hoping to work up to it <llano>futurile: but I will say, having never created packages in my 5+ years of using gentoo. I've managed to build a few things using guix, and it feels a bit magically when things start working <futurile>llano: yeah I think it's actually "doable" you just have to do it in small pieces <futurile>llano: you know if you're up for a 50 minute video ;-) <llano>futurile: for sure, I'll check it out. Thanks!