IRC channel logs
2024-11-23.log
back to list of logs
<podiki>we dont'set CC by default as far as i remember, no <podiki>you'll see some packages setting/do something for this in a phase <podiki>e.g. try a "git grep CC" in packages <anemofilia>x8dcc: Sorry for the ausence, I was at uni. I'm happy you managed to do it :) <x8dcc>I already looked in the source (I am learning, ieure). I think I managed to fix that, but PREFIX is still weird. I kind of crashed my whole WM in the process (in my non-guix machine) <x8dcc>anemofilia: Ah, hello. Don't worry, I have been getting a lot of help <x8dcc>ieure: Are you sure guix sets $PREFIX? I tried using `PREFIX=/asdasd make install` on my host machine and it seems to work: `mkdir -p /asdasd/bin; mkdir: cannot create directory ‘/asdasd’: Permission denied` <ieure>x8dcc, You're right, I misunderstood this. gnu-build-system's configure phase passes --prefix= to ./configure. <x8dcc>In the dwm package definition it replaces "\\$\\{CC\\}" with "gcc", probably what podiki meant <podiki>others will do (setenv "CC" "gcc") <x8dcc>But if you use "?=" in makefile, it still won't work since CC has a default value in make. Unless you use -e <x8dcc>right, make-flags would work <x8dcc>I'll say one thing: All this long journey is making me learn a lot about how to make robust/agnostic build systems <podiki>you certainly will learn a lot about the worst practices out there! (not this was a case of that, but packaging in some ecosystems is difficult/impossible/ugly) <podiki>ACTION finally gets to all that other stuff to do...catch ya later guixers <rekado>NFS is broken on my aarch64 system. The logs show that there's a kernel bug involving recovery: "kernel BUG at fs/nfsd/nfs4recover.c:534" <rekado>this causes rpc.nfsd to terminate, but shepherd considers the service to have started anyway <rekado>as a consequence the "nfs" service (which depends on rpc.nfsd) is stuck on running "exportfs", which will never terminate. <rekado>this is with Linux Libre 6.10.14 <rekado>because of this service being stuck I cannot reboot (without a hard reset), nor can I upgrade without hacks. <rekado>I'll try to reproduce this with an LTS kernel <jonsger>I get a "Throw to key `record-abi-mismatch-error' with args `(abi-check "~a: record ABI mismatch; recompilation needed" (#<record-type <package>>) ())'." error when building with `guix build --load-path=. some-package". But it's not the guix channel itself how can I recompile another channel? <x8dcc>anemofilia: Yours is ASCII-armored, mine isn't. That shouldn't matter, though; according to "(guix)Specifying Channel Authorizations" <x8dcc>I am not sure if the filename matters, anyway <anemofilia>jonsger: Oh, I'm getting some such message recently too, idk why <x8dcc>Hmm, I can try using ASCII-armored <anemofilia>x8dcc: Just saw the doc, apparently there is no problem in using binary key <x8dcc>I rather use ASCII-armored, anyway. At first I added the binary one because I didn't know it supported both <jonsger>anemofilia: and idk how to do this recompilation thing :( <anemofilia>x8dcc: Try to use the ba5e7eef57c8e4ecc43bf223c7ed9610d18c3d41 commit <x8dcc>Guess the .guix-authorizations is needed from the start <x8dcc>Now one last question for today. How can I choose which "dwm" I want to install? From scheme I guess it just depends on which module I include, but what about when using "guix install"? <anemofilia>x8dcc: A bit opinionated, but I myself never use guix install, it introduces state that isn't managed declaratively, I would use guix home for that <x8dcc>I plan on using guix home for these packages, but I still would like to know <anemofilia>`guix package -e '(@ (x8dcc-channel packages suckless) dwm)'` <anemofilia>Idk if there is a simpler way (one that doesn't involves doing manifests or something like that) <x8dcc>Oh, and it downgrades the DWM from upstream. Perfect :) <x8dcc>Well, that's it for today. Once again, thank you all for your help, really. <dajole>Thank you everyone involved for the excellent documentation for Guix! I still have much to learn and am just getting my bearings, but this is made much more pleasant by the thoughtfully written documentation. <hapst3r>Is anyone else having trouble with guix pull? Since a week or two it doesn't work anymore on my laptop where guix is installed as a package manager. It indexes what needs to be changed, and around the time when the commits are authenticated, I get an "fport_error: Input Output error" <arni>hello :)! does anyone know of good Matrix clients that one can use on Guix and which are fully compliant with FSF free-software rules? <sneek>Welcome back arni, you have 1 message! <sneek>arni, Rutherther says: if you have just one disk, do not make separate esp, there is a good chance your system wont support it. Most systems support one esp per disk. <hiecaq>arni: You can use emacs-ement if you happen to use emacs too <arni>def, was thinking of it since i'm planning on really delving in emacs <arni>i'll take the time to try it then, if you think the same. thank you :) <arni>im guessing it wouldn't support vid calls though, no? <hiecaq>Yeah, I never tried to see if that works and I'll guess no. I used ement for a while when this channel was still bridged to Matrix, and stopped after that. Overall its UX is great enough. <csantosb>Ey, is there any reason why one cannot `guix install rust@1.79' ? <csantosb>I mean, I see define-public rust-1.79 in rust.scm <Rutherther>csantosb: only one rust version is maintained and exposed at a time, the rest are in the bootstrap toolchain, but it's not possible to reliably use them, so that's why they are hidden. <csantosb>Out of curiosity, they're hidden how exactly ? Both rust and rust-1.79 are defined public. <Rutherther>csantosb: there is an attribute hidden set to true, so specifications don't match them <Rutherther>Franciman: I think you've asked that multiple times here without an answer, maybe it would make sense to ask on guix-devel instead? <Franciman>my real beef is having a newer telegram-desktop version <Franciman>maybe i should give up and use it through matrix <Rutherther>and newer version has something that needs newer glibc? <Franciman>Rutherther: i lowkehy suspect that the glibc version somehow impacts on this bug i'm having for telegram-desktop <Franciman>because telegram-desktop 5.5.5 with glibc 2.41 worked smoothly on arch linux <Franciman>so there is either something deeply rotten in the way telegram is packaged here <Franciman>or it must be some difference in the dependencies <x8dcc>Hello, does anyone know what package contains the tic(1) command? "compile terminal descriptions for terminfo or termcap" <civodul>x8dcc: ‘guix locate tic’ tells me ‘ncurses’ <x8dcc>Forgot guix locate existed, thanks <dariqq>are the extra outputs "that just work" documented somewhere? It looks like "bin" does but "sbin" not <dariqq>i guess i can just add a --sbindir to the configure flags <dariqq>yeah it seems (some) build systems take care of things when there is a "bin" output , but not "sbin" <luca>Do people here tend to test patches that have been submitted to the mailing list? And report that they work/don't work as expected <futurile>luca: you can review a patch that's sent to the patch mailing list, and if you click the buttons on QA then that will highlight to a committer that someone's tried it out <futurile>just replace a numbere here with the one you're interested in, and click the buttons if you're tried it out. <csantosb>luca: sometimes, and you (I) learn something new every time you do so <luca>Ok. I was interrested in trying out #72564 but the QA page is not available <luca>wasn't there a bot sent issue links when mentioned? I miss ya buddy <futurile>luca: OK, it means that QA hasn't "processed" it yet - it's because QA is really struggling at the moment <luca>Oh that's unfortunate. The patchset was submited in august, so it must be really bad <csantosb>It's unusual, by now, to have reports from QA. Not a limitation, though, to review the patch. <futurile>luca: it probably skipped it at some point <futurile>luca: if you want to review it, you could use the process that's outlined here. Basically you download it, and 'bump' the patch with a v2 marker <futurile>luca: all the steps on how to do it are on that page <luca>In any case, I was more interrested in testing the patch and seeing that the program works, not "reviewing the code" <futurile>reviewing means testing it and saying "it works" - it's a way of getting the patch into the distribution <futurile>luca: basically - since no-one has looked at it since August - the chances of it getting into the distributio are practically zero unless someone steps up and "advocates" for it - in a way doing a review is advocating to include it - it's someone saying "I care about this patch, and it works" <resu>is there an env var to tell if your in a "guix system container sys.scm" or "guix home container home.scm" ? <futurile>resu: not sure, I guess you can check with 'env' - I think there's a different profile set when you're in guix home (again not sure) <resu>futurile: thanks for the tip im looking at env (!printenv) now <resu>only thing I can determine is there are less ENV vars overall.... printenv | wc -l ? <resu>27 vs 73 in my normal config <luca>oh opsy, I misunderstood <Rutherther>(at least I got from the question to distinguish one from the other, if it's from the underlying system, then my bad) <graywolf>Huuh, can I send a signal to shepherd via `kill' to re-create its socket? I managed to clobber it, and would like to get it back, but cannot do it the easy way by restarting shepherd since that kills my Emacs. <OriginCode>Hi, I was trying to install Guix on my PineBook Pro, my USB to ethernet adapter doesn't work as it doesn't have free firmware, is there any good adapter that I can use with Guix System? <civodul>graywolf: not really! you can send SIGINT so that it shuts down, and then you restart it <civodul>should we have it handle SIGHUP or SIGUSR2 or something? <graywolf>civodul: Yeah, I know, but that kill my Emacs so I hoped I could avoid it <graywolf>Not sure, maybe it would just be enough for new shepherd not to overwrite the socket it previous is still running... Would that be possible to detect? <civodul>not sure, because lingering sockets are tricky <civodul>you basically need to delete them if you don’t want EADDRINUSE <graywolf>I was thinking something like that shepherd could try to connect first before deleting it to see if it gets connection refused. <graywolf>But yeah, maybe this is such a edge case that it is not worth it <civodul>edge case, but Guix Home has a tendency to launch multiple shepherds… <graywolf>(Out of curiosity, how do *you* test shepherd locally? Sure, now I will try to remember to add `-s /tmp/foo' every time but seems error prone.) <civodul>i test it primarily in the source tree <civodul>(with the System and Home replacement tricks i sent on the list) <civodul>but there’s already a lot of testing that can happen in the source tree <graywolf>No I mean when I run `shepherd -c test.scm', it clobbered the socket. So I just wonder whether you remember to always pass the -s, or if there is some other trick to it. <graywolf>(`guix shell -f guix.scm -- shepherd -c test.scm' or what the command line exactly was, do not remember exactly) <civodul>first, i use ‘guix shell -CP’ for my dev env <civodul>there i run ./shepherd -I -s sock -c whatever.scm <graywolf>Hm, I was not able to get the -C option working (I usually use it as well, but did not work with shepherd). Maybe I was missing the -P. <graywolf>I got this error: shepherd: error: "test.scm": exception thrown while loading configuration file <graywolf>Without any details, so in the end I figured out that removing the -C makes the error go away <graywolf>And, no, the -P makes no difference... Hm. Is there a way to make shepherd print the exception? <graywolf>Oh, so *when I add `-l log'*, it starts to output additional error details to *standard output*. <graywolf>Now I see the error: While loading configuration file 'test.scm': "Syntax error:\nunknown location: _: bad use of '_' syntactic keyword in subform _ of _" <graywolf>So something related to locales I assume <civodul>most likely missing (ice-9 match) or something <civodul>the error is printed on stdout even without ‘-l’ <civodul>oh right, it works it you replace λ by ‘lambda’, wtf <civodul>files are supposed to be read as UTF-8 by default <graywolf>One difference I see that I am running the shepherd package built from guix.scm. <graywolf>civodul: shameless plug, patch #71262 would likely prevent this issue... <civodul>but the lambda is also a shepherd bug <graywolf>I would assume (since there is no utf-8 capable locale in the container, and LANG not set) it converts the lambda symbol to ? during reading the file. <graywolf>I still hold the believe guile should (by default) error out on conversion errors instead of this silent data corruption it does <carloratm>what's the command to execute the tui installer? <luca>Ok so I read that libreplanet article on 2024 guix patch review and honestly I am more confused. I just want to say that the patch set works fine on my machine. How do I do that exactly such that it registers in the QA system? <Rutherther>luca: go at any issue on the qa link. Scroll down and there is a form, it will craft an email for you to send. Don't forget that it's important to send it to control e-mail address. You can just change the stuff for another. But I am afraid it won't create the issue in qa system. Not even sure if you can do that, maybe it has to come from a maintainer <luca>And if there is no QA link available? Can I craft this email manually? <luca>I guess I can go to an existing QA, use that form, and edit the issue number <dlowe>OriginCode: I had the same problem on the pbp -- I ended up using a usb-to-ethernet adapter <dlowe>OriginCode: I had a lot of problems with software supporting the pbp, even on other distros. I gave up using it as a daily driver. <x8dcc>What inputs should I add to a package in order to use `useradd'? <x8dcc>Either way, I am not sure how I will be able to use `useradd' without root privileges <Rutherther>x8dcc: you won't be, of course, so wherever you put it, you will have to call that script/program with sudo so it can run useradd properly <Rutherther>or did you mean to use it inside of a build? that's not possible, the build runs in an isolated container and doesn't have any side effects, only output folder in store is created by it <x8dcc>I meant in the build, sorry. The installation phase creates a user for that program <x8dcc>Is there a way that I can specify in the build process that I want to create another user? <Rutherther>no, the build process is for _building_ packages <x8dcc>I assume that there are many programs that create their own users. How do they do it? <x8dcc>Or outside the build process. I meant when installing a package in general <Rutherther>on guix system, if you want your program to come with an account, make a service for it that will give you the package in profile as well as ensure the user is created. On non-guix system, not possible, you would have to make your own system activation environment, and I don't think anyone has done that, since that's what guix system is for <x8dcc>Indeed, if I install (the upstream version of) this package on Arch, it complains about "slock: getgrnam nogroup: group entry not found" <x8dcc>Is there a way of notifying the user somehow that it should create a user? <Rutherther>x8dcc: I don't think so. The most you can do is put it to description of the package, but I don't know if many users read that <x8dcc>I could put it in the build process, but that won't show when installing from substitutes AFAIK <x8dcc>I can try to modify the program, and at least try to print a nicer error message <cbaines>luca, QA has limited resouces and those patches were sent long enough ago that it's no longer looking at them <cbaines>if you resend the patches to that issue, then QA will take notice <luca>I'm not the author though <cbaines>luca, you don't need to be the author to resend the patches <cbaines>just trying to keep QA running has taken up all my time and energy, and I haven't even been sucecssful <luca>cbaines: and if I am not the author, and send the patches again, should I also resolve what my comment suggests? (in my case specifically it's deprecating a package instead of removing it) <yarl>cbaines: Oh I'll take a look, that seems a lot of work. Thank you <x8dcc>I am tweaking my system configuration, and when reconfiguring, it says "error: esrvice 'term-tty1' provided more than once". However, I am not providing that at all <cbaines>x8dcc, that probably means you've got the %base-services or %desktop-services more than once <x8dcc>Hmm... I am trying to avoid using %desktop-services. I am adding some items to %base-services, though. Maybe one isn't needed: https://bpa.st/BR6Q <cbaines>%base-services includes mingetty-service-type for tty1, so that'll conflict with what you've got in your configuration <x8dcc>I assume that happens with virtual-terminal too <x8dcc>Okay, it seems to be progressing after removing those 2 services <x8dcc>I am also not sure if I should use login-service-type, elogind-service-type, or both <dariqq>building the guix package now takes forever with the #:parallel-build? disabled :( <x8dcc>I guess I am used to elogind from other distros, but I honestly don't care as long as it's a simple TTY login <luca>Thanks for the help cbaines! Really appreciate it <dariqq>25 minutes for make and another 12 mins for make check <Rutherther>x8dcc: it's not elogind or login, login-service-type gives you pam service for program "login", and other programs that just use that. elogind is more like a session/device manager. So you should usually have login-service-type, and as for elogind, its alternative is seatd, you usually need one of those if you are using gui. <lilyp>the fixes for gnome-team get weirer and weirder <marmalade>Does anyone know what could be causing this? <marmalade>I have no idea what's going on here, or how it's happening. All I did was install artanis, and then try to load the module. Not sure what's going on. <Rutherther>marmalade: are you on a foreign distro? do you have LD_LIBRARY_PATH set? <marmalade>Rutherther: i looked through the manual again and the only reference to LD_LIBRARY_PATH I found seems to suggest that maybe i could fix it by pointing it at my ~/.guix-profile/lib? <x8dcc>Is there some way of creating a bash symlink in "/usr/bin"? Just like for "sh" <marmalade>lmao jk i cat set the LD_LIBRARY_PATH variable because when i do my shell locks up <dariqq>x8dcc: look for extra-special-files in the manual <Rutherther>marmalade: no, why I asked is that you should not have it set in the first place, and if you did, it could cause trouble like that <Rutherther>I am confused, I thought you said you didn't have it set, so what fixes it? <marmalade>i thought i needed to set it and couldn't but if it doesn't need to be set then it's fine <Rutherther>alright. I don't really see anything wrong. I remember that few months ago someone had a similar issue with libraries, and the cause was some kind of an antivirus that somehow was loading wrong libraries. I forgot the name <Rutherther>btw is the guile you are running from gnu store or from your distro - how did you install guile/guix? <Rutherther>okay, and can you run other commands like guix pull, or do you have issues with all? <Rutherther>I don't know if that's going to fix it, but have you tried just using the guix you obtain from guix pull instead of your distro's? <marmalade>Rutherther: i have no idea what that means lmao <Rutherther>marmalade: guix pull gives you guix under ~/.config/guix/current/bin/guix, but as you sent your profile file, it looks like you are already sourcing its profile, so you should have that in path <marmalade>Oh yeah, which on guix gives me ~/.config/guix/current/bin/guix <marmalade>cos when i installed artanis it was complaining about changing my env vars still lol <Rutherther>marmalade: if you aren't using some kind of an antivirus, the only thing I can think of is corrupted files (and if it's not that, I really have no idea), can you try older guix version - ie. try /var/guix/profiles/per-user/$USER/current-guix-X-link, where X can be for example 1 <marmalade>i have no idea how the files could be corrupt and i reinstalled artanis multiple times <Rutherther>marmalade: the corrupt files would be the libraries. you would have to run guix gc with verify flag and set it to contents <x8dcc>dariqq: Sorry for the late reply, but that works perfectly, thanks :) <Rutherther>how to run a program with a flag? --verify="contents" <Guest51>Hi, i installed guix on Debian stable (bookworm) some months ago, and i want to install a package from it. I did a `guix pull` but it gives me the following error : "guix pull: error: reading file `/gnu/store/psv1j490rzfxv6r55qk3ap7rnajgrgmy-guile-3.0.7.drv': No such file or directory" Does anyone know what is going on and how to fix this issue ? <Rutherther>Guest51: can you try running "guix gc --verify" and see what it tells you? <Guest51>Rutherther : tons of lines (which i won't paste to avoid flooding), the last two are : path `/gnu/store/zwh4q1k3rp99krll934pkqj27idl01ix-tar-1.34.tar.xz-builder' disappeared, removing from database... <Guest51>path `/gnu/store/zwvla1q7jllcb9aznf48vi8mbfs0zlg4-libffi-3.3.tar.xz-builder' disappeared, removing from database... <Rutherther>Guest51: alright, so that's likely the cause, your store seems to be corrupted. To fix it, try "guix gc --verify="repair"". Did you have a power outage when running something guix related? <marmalade>Rutherther: verify came back clean - one thing, i'm pointing to artanis in .guix-profile, not current, idk if that means anything <Guest51>Rutherther : not that i remember of. <Rutherther>Guest51: in that case I would also recommend using some disk check tools to check if your disk is fine. Files should not really be getting corrupted normally <x8dcc>After installing "mandoc", why does "man printf" say "man: outdated mandoc.db lacks printf(1) entry, run makewhatis /gnu/store/<snip>-profile/share/man"? <Guest51>Rutherther : your fix worked (run as root), thanks a lot (i am completely new to guix). dmesg does not show any I/O errors, i will do some badblocks and smart checks. <Hamled>Does anyone here do rust development using the standard rust package and rust-analyzer? I was getting an error from rust-analyzer that it could not find the rust-analyzer-proc-macro-srv executable in the toolchain's sysroot. It appears that customizing the build for the rust package can cause it to build and install that binary in the sysroot, but I'm not sure if there is a simpler fix that other <Rutherther>dajole: if you mean the one referred to under local-file call, then relative to the source file where you use that <dajole>Thank you both for your replies! So if I'm understanding you correctly, if I used it in my `/etc/config.scm`, I'd put the file in `/etc/`? <Rutherther>dajole: if you are going to put in ./key.pub, and your config is at /etc/config.scm, then the file will be /etc/key.pub, yes <dariqq>you can also use plain-file instead of local-file which will write a string to a file for you <marmalade>Rutherther: is there really nothing else i can check? <Hamled>marmalade: what output do you get from `strings /gnu/store/f9biyanh9rm1mik8yb43fz22j63rd61l-nspr-4.35/lib/libnspr4.so | grep gnu/store` <Hamled>`guix shell binutils -- strings /gnu/store/f9biyanh9rm1mik8yb43fz22j63rd61l-nspr-4.35/lib/libnspr4.so | grep gnu/store` <x8dcc>I might be able to contribute to the main guix channel with a font. However, I am not sure what (license ...) I should use for this: https://bpa.st/ULOQ <Hamled>marmalade: what's the mechanism used for installing artanis (so i can try it on my machine, which appears to have the same libnss/libnspr as yours) <Hamled>oh uhh, what does `readlink -e $(command -v guile)` say <Hamled>marmalade: you said earlier that it was guile from your distro, i missed that. This is likely the source of the problem -- when guile is compiling artanis it is attempting to load the required libraries like libnss, and one of them wants libc.so.6 -- but that was already loaded by guile when it started up. Except it's the libc.so.6 from your base operating system, not the one that Guix compiled <Hamled>The solution would be to `guix install guile` and make sure that you're using that copy which Guix installed (maybe running `hash guile` would update your shell to find it, but starting a new shell might be cleaner?) <hapst3r>Is anyone else having trouble with guix pull? Since a week or two it doesn't work anymore on my laptop where guix is installed as a package manager. It indexes the commits, and around the time when the commits are authenticated, I get an "fport_error: Input Output error" <marmalade>Hamled: Ahh. Would it be necessary to remove my distro guile or nah? <marmalade>also the response from readlink was `/usr/lib/x86_64-linux-gnu/guile/3.0/bin/guile` <x8dcc>Is there a way of rebooting/shutting down guix system as a user? <Hamled>it shouldn't be necessary, the goal of the Guix profile script that is being sourced when you start a shell (according to one of your earlier pastes) should be to setup the PATH variable so that executables installed in your Guix profile are found before ones that may be just in the general system, but you might want to double check that by looking at `echo $PATH` after starting a shell (something <Hamled>like `/home/username/.guix-profile/bin` should show up near the beginning) <marmalade>Alright! Running guile directly from .guix-profile/bin works! <marmalade>I'm still not getting how the guix profile stuff works though. I have two assignments to the same envvar and I don't understand why <marmalade>and for whatever reason my shell doesn't want to default to the guix installed one <marmalade>I need to have it set as .config/guix/current so i can use the latest guix binary(?) <marmalade>and then also as ./guix-profile for actually using guix(?) <Hamled>my understanding (i'm far from an expert) is that these two sections "layer", so first you get the configuration from your "Guix profile" and then additionally you get the configuration from your user's installation of Guix itself <marmalade>so should i be doing it in reverse then? I'm setting it to .guix-profile before current <Hamled>I think that is the right order, in theory the only thing that the profile in .config/guix/current should provide is the guix program itself, so having it come last means it takes precedence <marmalade>cos i think other stuff references GUIX_PROFILE <marmalade>i switched em and which guile shows the right one now <Hamled>interesting, what is your PATH variable now <marmalade>`/home/marmalade/.local/bin:/home/marmalade/.volta/bin:/home/marmalade/.guix-profile/bin:/home/marmalade/.guix-profile/sbin:/home/marmalade/.config/guix/current/bin:/home/marmalade/.volta/bin:/home/marmalade/.cargo/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/local/go/bin:/home/marmalade/.local/bin/` <Hamled>okay, and the guix command is still coming from .config/guix/current/bin/guix ? <robin>x8dcc, maybe loginctl from elogind? loginctl poweroff/reboot/... <x8dcc>robin: Perfect! I remember using that in other systems, but I didn't know loginctl was from elogind <Hamled>okay cool, sounds like you've got the right setup :D <marmalade>but yeah the documentation needs to be updated for that i don't think i would have ever figured that out on my own <robin>marmalade, current before guix-profile is what my $PATH has