IRC channel logs
2023-12-04.log
back to list of logs
<civodul>efraim: is ncdu tuned for skylake going to browse my disk faster than before? :-) <alethkit>is there a long-term solution to inode exhaustion that doesn't involve backup and a different filesystem? <ieure>alethkit, If your computer has a place for a second disk, you can add one and move part of your filesystem there. If not, you can resize your FS and partition, then make a new partition and move part of your FS to it. <ieure>Though I think with GuixSD, most stuff is going to be in /gnu/store (which you can't readily break up) and /home, so it's not as easy on a tradlinux where you can shove /usr on another disk or whatever. <alethkit>and I think I still have persistent state somewhere <ieure>It's surprising that you ran out of inodes. Guix will use more overall, but I wouldn't expect it to be too too much. Do you have a good sense of what's consuming them? <alethkit>It's the fact that I expanded my filesystem from when it was much smaller <alethkit>apparently increasing the file size does *not* increase the number of inodes <ieure>Oh yeah, that could definitely be the case. <ieure>If it's typical ext3/4, those have a fixed number of inodes which get allocated at mkfs time, based on the disk size. <apteryx>vivien: it'd be nice if you could use 'git send-email' some day, or manually use 'X-Debbugs-CC' instead of plain CC, so that we get back the bug number instead of 'guix-patches@gnu.org' in the To: field :-) <Guest5>Hi, just wondering if anyone can help me out with something... Ive been having issues with my fans, and want to have "fancontrol" run as root every boot. What would be the easiest way to implement this on a Guix system? <apteryx>a one shot shepherd service sounds like a natural means to accomplish this <alethkit>does guix offload work with an ssh agent, or passwordless pubkeys only? <Guest5>Sorry, kind of a noob with Guix, could you point me to the right part of the manual to find that? I was looking at the scheduled job execution page <apteryx>alethkit: strictly works with ssh agent, IIRC <apteryx>that's a limitation in the underlying libssh(2?) used, also IIRC <apteryx>requires an agent with the key in in <alethkit>it doesn't seem to want to authenticate, though <PotentialUser-93>Hello, I'm having difficulty cloning the guix repo and I'm not sure why. When I try to clone using my system's default git I see "git: 'remote-https' is not a git command. See 'git --help'.". When I try installing git from guix and then cloning I get "fatal: unable to access 'https://git.savannah.gnu.org/git/guix.git/': server certificate <PotentialUser-93>verification failed. CAfile: none CRLfile: none" I'm not really sure what is going on since I was able to clone the guix repo last week when working on a package. <jeremyc>see if a guix install git fixes the issue. <PotentialUser-93>If I disable SSL with GIT_SSL_NO_VERIFY=true the clone works, but obviously I don't want to do that <jeremyc>oh, ok. should have read more. I had the issue a few days ago as well, the initial one. Newbie here, probably shouldn't have stepped in :-) I'll wait for the more experienced to respond. <PotentialUser-93>It's odd because I was able to clone and submit a patch with git send-email a week ago. Today I tried to do a git pull and got a strange error so I assumed something was wrong with my cloned repo. I deleted and when I try to reclone I get where I am now <jeremyc>I see references online about this occuring when system clock is way off. That'll be my last suggestion, then others with more guix experience can chime in. <PotentialUser-93>My system clock is accurate. I just did "git config --global http.sslCAInfo /etc/ssl/certs/ca-certificates.crt" and it looks like that fixed the issue. <PotentialUser-93>I have no idea why git would've been able to find the certs a week ago but not now <ieure>Hmm. I'm messing around with packaging fractal (the new Gnome Matrix client). It needs newer gtk than Guix has, which needs a newer glib than Guix has. <ieure>I made a package in my channel with newer glib, which inherits from the stock glib, and in the gtk package, I swapped the stock glib with mine. <ieure>If I build either fractal or gtk, it builds my glib (2.76.6). But if I'm in my channel repo and run `guix build -L. glib', it builds the stock 2.72.3. What's up with *that*? <ieure>If I run `guix build -L. glib@2.76.6', it tells me: guix build: error: glib: package not found for version 2.76.6 <Groumf>Hello guix guys. Is there some doc somewhere on how to install guix without sudo? <Groumf>I wish to use root with ```su -``` and not install sudo. <Groumf>(damn me. that habit of putting command between 6 backticks…) <ieure>Groumf, I don't understand your question. You can `su -` and then run the command after `sudo`. <Groumf>hmmm let's put it that way, I just don't want sudo installed on the system <ieure>You can install Guix and then remove the sudo package. <ieure>It doesn't hurt to have if you don't use it, though. And it's the default on basically every Linux distro, because it's more secure and convenient. <Groumf>hmmm ok, I'll just do it like that then <Groumf>I mean, I am trying to have the whole system definition in a scheme module <Groumf>but I guess it's a bit too advanced for a beginner like me <ieure>Why do you prefer `su -' so strongly? <Groumf>I don't see how sudo provides more security. When it arrived in debian, around 15 years ago, I always joked that one day a CVE would come. <Groumf>Well that day arrived… not a joke anymore <Groumf>So, I think it's just something that widens the attack surface <Groumf>Now it comes with some practices, like don't stay too long with a terminal opened as root. <Groumf>But apart from that, sudo mostly means that if a sudoer is compromised, you are done. <ieure>Hm, interesting. Thanks for sharing. I agree any suid-root binary brings some level of risk with it, but since all my machines are single-user, it doesn't make much difference. Maybe we have different usecases or risk profiles. <ieure>OpenBSD has a doas tool, might be worth looking into porting that, if you're interested in a similar tool with better pedigree. <Groumf>hmm did not know about that one, thanks for the pointer. <ieure>If you want an operating-system definition without sudo, I think you can remove it from %base-packages. Not sure of the exact code to make that happen. <Groumf>Ok that's what I was looking for. "Where to look?" <Groumf>Thankfully, guix is really easy to read. <ieure>Lisp is either very easy to read, or impossible. :) <xelynega>gnu/system.scm has it in setuid programs, and gnu/system/hurd adds it to setuid programs for hurd from what I can tell <xelynega>So looks like it implicitly comes in from it being included in default setuid programs, wont be directly in the base packages <Groumf>yup, there are many occurences actually. <Groumf>Is it crazy to just rewrite system.scm? <Groumf>It looks a bit like a big fork then, not sure I want to do that. <ieure>Groumf, I would say it's excessive and unwarranted. But Guix is a hacker's distro, so hack away. <ieure>You don't have to remove it from the Guix source. You can remove the sudo package from the list of packages in /etc/config.scm, is what I was saying. <Kolev>Does anyone else have issues using noweave? (Package noweb.) <vivien>apteryx, I didn’t know what that was for. You will have your X-Debbugs-CC! Fortunately, that’s a format-patch argument, not a send-email one. <xelynega>I'm going to spend the holidays cleaning up the packages/services to make upstream PRs(and maybe some blog posts), hopefully someone else gets some use from it. <Guest1441>Does anyone know of any efforts to package github.com/intel/compute-runtime for Guix? I'd like to try, but it looks big and scary. <attila_lendvai>Guest1441, if that free software? it not, then it does not qualify for Guix, only into that other channel that accepts non-free software <pranshu>Is there a way to have all your config files, including guix-home in one folder? <gabber>pranshu: there probably is. what is holding you back/what issues are you facing? <gabber>or do you mean the automatically generated and moved files when you "including guix-home"? <jas>i'm upgrading an old guix system and got this message: guix system: error: package glibc-locales@2.37 does not support x86_64-linux <jas>did something change wrt glibc-locales? i have it in the packages section of the operating-system clause <pranshu>gabber, I am just dont know what to do <pranshu>Its not that I am facing any issue, I would just like to know how to do that <gabber>if you mean "~/.guix-home" then you might be able to achieve your goal (with some hacking) but it might not be what you actually intend or want. ~/.guix-home contains all the configuration that you specified in the config file you passed into the $(guix home reconfigure your_config.scm) command <pranshu>Basiclly I want to make an ~/.dotfiles directory, and make it so that if I have mutltiple systems, all I have to do is simply paste that repo and I will get an identical setup <pranshu>I will have all my configs in the .dotfiles folder, so no downloading from github or something <gabber>you can do that with guix home, i.e. the home-files-service-type. but careful: applications like Emacs expect the configuration file to be editable, so emacs configuration need additional care for something like that <pranshu>will the home-files-service-type work with directories? <pranshu>so all I have to link is one simple ~/.emacs.d/ and thats all? <gabber>the gist of it would be to keep all your hand-crafted config files and you guix-home-config.scm in the same directory (with the latter referring to the former with relative paths) and then you could simply reconfigure your home with that config file <gabber>Chapter 13.3 in the reference manual should cover most of your questions. and as i said before, no, with emacs it's a bit more complicated, since emacs expects your main config file to be writeable. there have been a couple of trials to get some sort of emacs-home-service merged into Guix but AFAICS this hasn't been merged (yet). <pranshu>I think I shouldnt have any problems with emacs if I use the no-littering package and set the editable directory in ~/ folder <pranshu>also then how do some people use gnu stow <pranshu>also I think you can change the user-emacs-directory with the bashrc <Guest1441>attila_lendvai: Yes, I believe it's all MIT-licenced by Intel. It's their successor to beignet (guix packaged). I think this looks too ambitious of a packaging project for me :-( But thanks for your pointers. <ekaitz>does anyone experience hanging tests in libtorrent-rasterbar? <ekaitz>it has been testing since yesterday... <Guest1441>attila_lendvai: oh, that's a good idea. I'll definitely get in touch at guix-devel if I decide to give this a try. Thanks! <Guest5>Hey, I can't seem to find this anywhere... how do I make a simple one-shot service for a guix system that does nothing but run "fancontrol" as on boot. I want to define this in my config.scm but it's not the end of the world if I can't <attila_lendvai>Guest1441, you can use that example, and replace the start GEXP with a single (invoke ...) call <Guest5>Oh wait, i just read it... I think there is enough info in there for me to work with <attila_lendvai>Guest5, try to work it out, and ask away if you reach the end of your frustration tolerance. basic scheme should be enough to modify that example. <Guest5>Cheers, I've been trying to modify examples all day in between work, kids, and sleep deprivation... Wish me luck haha <attila_lendvai>Guest5, a tip: you can use a `guix repl` to try out the (invoke ...) part, and then copy-paste it. <attila_lendvai>Guest5, for invoke you need (use-modules (guix build utils)), or you can just use (system "ls -l") instead. <ekaitz>i think b1cca212640 introduced some kind of regression that makes libtorrent-rasterbar tests hang <Guest5>attila_lendvai, so what line would actually define the command to run? <attila_lendvai>Guest5, (begin (use-modules (guix build utils)) (lambda _ (invoke "ls" "-l"))) <attila_lendvai>Guest5, or it's much simpler using vanilla guile: (lambda _ (system "ls -l")) <Guest5>"ls -l" being the command to run? <attila_lendvai>Guest5, i.e. a single lambda instead of the entire (begin ...) part in my example <gabber>i seem to be unable to build /gnu/store/i9r4lshlv2ffr5p7n3f6bz458hmla5pq-qemu-minimal-8.1.1.drv on my not-too-weak Debian CI server (8 cores, 16G RAM) via qemu-binfmt. it hangs in check phase at 13%. any ideas how i can still make that server build Guix system images for me? or where the issue emerges from? <gabber>Guest5: this looks right to my eyes -- does it compile and work? <attila_lendvai>Guest5, if you use (system ...), then you don't need the begin and the use-modules, just directly the (lambda ...) part. <attila_lendvai>Guest5, it's not a problem, but unnecessary complexity. those are only needed when using (invoke ...) instead of (system ...) <Guest5>Oh haha, it's a bit late now but that's all good. I can tidy it up later, I really just want to stop needing to run fancontrol every time i turn my computer on <attila_lendvai>Guest5, one reason why this may not work is that i don't know the value of PATH when this will be executed. hopefully fancontrol will be included. <Guest5>Good point. I am actually using a modified version of fancontrol, so I have provided the full path to that temporarily <Guest5>You know you're tired when you start the reconfigure using the wrong config file... It's giving me an invalid field specifier now that I am using the right file... Where do I actually put this in the file? <cbaines>I've restarted mumi (issues.guix.) on berlin as it seemed to be down <Guest5>Or is it meant to be a file of it's own? <gabber>cbaines: thanks! i wanted to ping people here but i didn't know whom to ping <gabber>wouldn't it be cool to have one of the bots manage pings for admins for these sites? <gabber>Guest5: if you share (the relevant part of) your config and the error message we could address the issue more appropriately <gabber>you put this in your (services) list in you operating-system definition <Guest5>it's a different error, so I think so... shepherd-root-service-type: unbound variable <cow_2001>the PEG tutorial of the Guile book is great, i think. i want more of that in every other section of the book :D <gabber>you need to put your s-exp at the same level as gnome-desktop-service-type and set-xorg-configuration :) <Guest5>The few moments of hanging when I reconfigure are promising... And it is doing stuff!! You legend! <gabber>no no, YOU legend :) now get your well deserved rest (or fun or whatever) <Guest5>Definitely rest, my youngest is due to wake up any moment now, seems like we got it done right on time. Thanks again <Guest5>Also, this was my first time asking for help, and I'm glad I did. <Guest5>There's still a problem... It comes up as enabled but stopped when I look at "herd status fancontrol-oneshot" <gabber>i think that's to be expected - a one-shot service only runs the start-lambda and is finished then <Guest5>Yeah, except it never started fancontrol... Don't worry, I think I've worked it out <Guest5>I think it's starting too early... I will try adding a 30 second sleep to the start possibly? <Guest5>That worked. Thanks for the help people, I will get out of your hair now <Kolev>I'm running low on disk space. What is the best way to run `guix gc`? <gabber>Kolev: kinda depends on your needs. i usually run it without any options (and then just re-build all the things i was still needing but had no references to) <gabber>civodul: i think that makes sense (supposed this option works on most systems and more reliably than just -P) <civodul>gabber: coolio, thanks for taking a look! <gabber>civodul: btw have you seen that i've submitted a patch for an easy issue you opened 2½ years ago (#48018) ? <civodul>gabber: i hadn’t seen, but that’s great news, thanks! <isaneran>I ran a command and it downloaded it, ran another command and it is downloading it again! <mrvdb>hi guix. I'm having troubles using mpv (core dumps) which point to the mesa package. Is there a way to downgrade the mesa package with guix and check if that really is the problem? guix install mesa@x.y.z does not work (no versions in repo i guess) i'm on ppc64le and gpu is amdgpu <gabber>mrvdb: you can try going "back" in time with $(guix time-machine --commit=YOUR_COMMIT_HERE -- shell mpv) <gabber>commit being any past (or future) commit in Guix' git history <mrvdb>gabber: ok, going to give that a try. /me goes commit digging <mrvdb>hmm, mpv throws and error MESA-LOADER: failed to open zink: /gnu/store/whajh9y5bpgs8gdwvz1xdwizsp1z6xsg-mesa-23.2.1/lib/dri/zink_dri.so Should that file be there? It is not. <efraim>ah, the zink error. I'm sure I've seen that before <mrvdb>efraim: that sounds hopeful, any links? <sneek>ieugen, dthompson says: thanks for the report, can you paste the contents test-write.log somewhere? we haven't seen this in CI or our own machines. <ieugen>I would like to see them merged, but I can't do that <efraim>didn't see anything in my Maildir, it seems the .bash_history on my VPS goes back years so I'm checking my quassel backlog <efraim>lol quassel-storage.sqlite is 742M <jeremyc>Does Quassel Core only work with the Quassel IRC client? Was looking for a nice solution to stay logging in when laptop goes to sleep, etc... seems Guix has services for this. <anthk_>jeremyc: does guix have the bitlbee service? <efraim>podiki: did we ever enable zink in mesa? <anthk_>with bitlbee you can connect to anywhere, even *external* irc servers <jeremyc>yes, it has that as well. Maybe that's a better option. I don't want to be locked into quassel client. <anthk_>with bitlbee you can use anything <jeremyc>I'll go down that road then, I have not used it in the past. Thanks. <mrvdb>efraim: looking at '-Dgallium-drivers' with guix edit mesa does not include 'zink' explicitly <efraim>none of the architectures in the mesa source code have zink by default, not that it would make a big difference since we explicitly list the drivers <efraim>ok, looks like my zink link wasn't really relevant <podiki>efraim: I don't think so? I don't remember such a patch <mrvdb>efraim: oh well, thanks for checking! <efraim>mrvdb: can you use not vulkan for now? I haven't really dug into where zink gets loaded <podiki>efraim: I'll update mesa again soon with the latest release (once a new point release is out) probably along with those xwayland patches if core updates isn't building then <mrvdb>efraim: i have no clue what that means <gabber>i am having trouble defining a relatively simple service: https://termbin.com/ecyf -- adding that service to an operating-system wouldn't even start doing anything "(resize-fs): unknown keyword or bad argument", though i am able to load it into a $(guix repl) and also do (use-modules (resize-fs)) on it <efraim>I mostly make sure mesa builds on all the architectures <efraim>mrvdb: using one of the options from 'mpv --vo=<tab><tab>' can you get the video to play? <ekaitz>efraim: i'm having build errors with ddcui <efraim>ekaitz: I think ddcutil is missing its pkg-config file <ekaitz>efraim: good, so you have it under control... i just saw your latest commit, that's why I decided to ping you <ekaitz>efraim: also thanks for pushing the tuning for zig and fixing my patch <efraim>ekaitz: civodul wants to know if ncdu is actually faster if its tuned :) I assume so, but I didn't check <ekaitz>efraim: in order to do that we need to move it to zig-build-system <efraim>we wrapped zig with -Dcpu=, I tested with --tune=x86-64-v4 and got Illegal instruction <ekaitz>let me take a look, i'll ping you later <efraim>If there isn't some way to benchmark it I'd probably end up looking at diffoscope again <civodul>most likely ncdu spends most of its time doing i/o <civodul>i don’t see how vector ISA extensions could make it faster <efraim>I hadn't really thought about that part :P <civodul>my suggestion would be to mark as tunable only packages that we know can benefit from it <civodul>(because it doesn’t come for free: CI ends up building several variants of the package) <ekaitz>in any case, building it with the proper buildsystem that actually supports cross compilation is good stuff <anthk_>the speed on ncdu will depend on the I/O scheduler for the HD/SDD <ekaitz>we can use another example package for this... something that has heavy computation... <ekaitz>soonish we'll be ready to package `bun` hehe <ekaitz>ah! also efraim we kinda have a zig-0.11 package but that binary of the wasm bootstrap is in the way <efraim>I turned on tuning for syncthing when I was testing tuning go but never committed the change <efraim>we'll have to decide about tracking zig-bootstrap to grab the known-good upstream commits for building from zig-0.10 to 0.11. Not sure how long that'll take even with tests disabled <ekaitz>Oh oh... >>> /gnu/store/ml1p2h805amf3m1bd3pvqm86vzn9z4q0-ncdu-2.2.2/bin/ncdu: error: depends on 'ld-linux-x86-64.so.2', which cannot be found in RUNPATH ("/gnu/store/bcc053jvsbspdjr17gnnd9dg85b3a0gy-ncurses-6.2.20210619/lib") <ekaitz>efraim: yeah, we are working on that, there are several versions there... ugh <ekaitz>shouldn't be the dynamic linker in the runpath too? <efraim>did you turn on runpath-vaildation? <efraim>yeah, it probably needs to be patched in zig somewhere <ekaitz>the build system probably doesn't disable it <ekaitz>ok i have ncdu running with the zig-build-system <ekaitz>it was easy but the runpath thingie i need to do something about in the zig-build-system <civodul>BTW, anyone submitting a talk for the Containers devroom at FOSDEM? <ekaitz>efraim: i forgot the copyright header haha kill me <ekaitz>i'm not sure about what to do with the runpath check anyway... is it ok to remove it from the build system directly? <graywolf>In general, is specification->manifest prefered over packages->manifest? At least that is the feeling I get from the docs. Is that correct impression? <gabber>graywolf: i think the former is easier since you don't have to (use-modules (gnu packages foo)) for every package since you only specify strings <yewscion>Recently, I've been noticing an error when I try to update my system or home profiles on any x86_84 machine: `guix home: error: package glibc-locales@2.37 does not support x86_64-linux`. Is this intended? I see that the package listing for glibc-locales does not list /any/ supported systems at that version... <gabber>yewscion: i think your guix is "out of sync" -- you might be able to resolve it by logging out and back in (iirc) <gabber>and before speculation may go off: you updated glibc-locales (as you should) but one of the profiles in action for some reason still refers to an outdated one <yewscion>gabber: I'll just reboot the server I'm working on, then. That should clean up any inconsistent state, yeah? <yewscion>Also, I have just now realized I could trigger a build anyway by manually asking guix to build glibc-locales, which currently defaults to the latest version available, which is the one my system is having issues with. It fails to build on my machine, at least in this odd state. Here is the error message from the build log: https://paste.debian.net/1300155/ <yewscion>itd: gabber: Going to revert to version 2.35, at least for now. <gabber>you could also try to build "from another point in time" with $(guix time-machine) (which should trick potentially malconfigured current system state) <ieure>Hmm, I didn't really understand about qa.guix.gnu.org. But it hasn't worked on a bunch of stuff I've submitted either. <civodul>graywolf: ‘specifications->manifest’ is more concise but also elss precise than ‘packages->manifest’, so it really depends on your needs <yewscion>gabber: itd: FWIW, reboot and downgrading did not fix this issue. Going to pin my core guix repo to the current live commit for now, as I think this is a wider issue, especially with all of the other issues linked above. Commit I'll be pinning to is 597f1cd1c46ffb92c3e0145de0071545a4c64865, though later ones before live might work. <yewscion>Scratch that, commit was the one that is failing. Currently searching for a working commit. <yewscion>9501d5388d0452eb7ce14baceef1c7ac90333de8 seems to work, going to step forward until it breaks. <yewscion>d15ffea6f47a40a9d36f3f32935e63f92e90af03 works, 7668bfa2227ca8c388e4020a5ba6ff33a291bf6e doesn't. Somewhere in that window, then. <Guest3906>Hello, I tried to use my Guix config as a channel, but I'm getting weird errors saying that there is no code for modules that are totally unrelated to my channel <Guest3906>Inside this channel I have my system configs, and some of them use modules from other channels. It is one of these modules that error out, however, the system config that contains this use-module line works fine on its own <Guest3906>The error happens during a guix pull, when building the derivation that is named just the name of my channel <ieure>Guest3906, You need to declare a dependency on the other channel in yours, in the dependencies field in the channel type. <Guest3906>Okay, thanks! But why does this happen? I already have that channel in my channels.scm. Does Guix suddenly forget about it during a guix pull? <yewscion>9442b53c6b4dbf078f37a52687a32ecbd2ca430d Is the first commit for which glibc-locales fails for me. <yewscion>Going to pin to ea348b105d1fb8f02b3ca8665c5ad33928f7483f for now.