IRC channel logs
2024-10-13.log
back to list of logs
<fnat>Anyone using 'home-unclutter-service-type'? I've got it as a home service but it doesn't work. The logs say 'unclutter: could not open display'. <fnat>Hm, ok, I modified the Home service so that it prints out all its env variables and it turns out that DISPLAY is undefined. <fnat>I might be missing some other service where DISPLAY gets usually defined? <fnat>Hm... it might be because of a missing '(requirement '(x11-display))' in 'home-unclutter-shepherd-service'? <fnat>Adding '(service home-x11-service-type)' to my Home configuration doesn't seem to be doing anything, although I wonder whether this might need me to log out and back in again for the DISPLAY env variable to be set? <jaft_r>acrow`: I'm not entirely sure I understood but, assuming I did, I think your issue might be using the same name for the modified package. If Guix can find a package, by name, that shares the same SHA256 hash in the store, it'll default to using that found package from the store (I'm assuming your modification of the package didn't include changing the hash). <jaft_r>I'm hazarding the guess that it's just reusing the original package rather than trying to build your modified version. If you give the modified package a different name, it'll try to buid (and use) it, for sure. <jaft_r>Ah; rereading it, I think I misunderstood and my advice probably isn't relevant. Sorry about that; feel free to ignore. <jaft_r>fnat: rather than missing requiring '(x11-display), it could just be missing specifying the DISPLAY variable. With the Redshift service, – on line 265 – it specifies environment variables and sets DISPLY by getting the current value of DISPLAY with "getenv". <jaft_r>Maybe adding #:environment-variables to home-unclutter-shepherd-service (within make-forkexec-constructor) in a similar way to redshift-shepherd-service might fix that error. <acrow`>jaft_r: Thanks for the thoughts. I tested the package to build; so, it is in the store. I think I have to be careful about the order in which I make module inclusions... more play is required. <acrow`>Moving (use-modules (gnu system privileged)) to after the definitions reassigned things but it still isn't what was intended. I suspect namespace problems ... maybe define-public is now appropriate instead of just define... <acrow`>That did not work. I am imagining that when I call define-public for the re-definition I trigger a recall of the associated module. Because it now asks for the slock module again when it is already called out above... Hmm. <acrow`>Another way to not succeed (define-public (@ (gnu system suckless) slock) modified-slock-pkg)... Hard fail on that try. <acrow`>Are packages 'lowerable objects'? Usable wo gexp for (file-append slock "/bin/slock")... I get an 'invalid field specifier'... <acrow`>I was trying to simply redefine the slock package to be able to take advantage of the privileged slock binary that gets called forth by some other package. Failing this, I just defined a variant and added it as another privileged-program. This too fails though, I think, because both privileged programs compete for the same /run/privileged/bin/slock filename. My variant is overwritten by the call from that other package. So, I guess <acrow`>I need to discover the desktop that also wants to make slock privileged and somehow make an appropriate transformation. <acrow`>I feel like I'm writing a diary or making a confession. :( Honest but, perhaps, wasting bandwidth. <Rutherther>acrow`: you cannot replace a package symbol name, because it comes from a different module. You need to put the package yourself to privileged-programs-service-type, it won't get replaced just by having the same symbol name. Additionally if guix puts it there already I am not sure if there won't be an ordering issue of privileged-programs-service-type programs. So you might have to ensure guix doesn't put it there <Rutherther>specifically, slock is defined in %desktop-services. So you might do something like "(modify-services %desktop-services (remove screen-locker-service-type))". Then you can add your own screen-locker-service-type. This will remove also xlock, but I suppose that shoudn't be a problem for you <fnat>sneek: later tell jaft_r Ha, thanks, that makes sense, I'll compare unclutter to Redshift as you say. <Rutherther>fnat: btw I would recommend sticking with fork+exec-command rather than making make-forkexec-construstor. At least when I last tried, the env var was not picked up with make-forkexec-constructor. I am completely clueless as to why, but just rewriting to fork+exec-command worked <fnat>Ha, thanks Rutherther, I'll have a look! <mccd>Heya, for systemd there is a nice program for securing credentials, systemd-creds. Is there something similar for guix? <mccd>or any recommendations for handling service-specific credentials? <bitspook>Is there any tool/script already in existence which checks latest vs available (in guix) versions of all packages? <Rutherther>bitspook: there is guix refresh that does something like that. It can show the versions and also update the source. Apart from that you can also use the transformations --with-version or --with-latest to transform a package to different version. Of course works only if there weree no changes in dependencies, build instructions... <Rutherther>probably won't work with all the packages, but should work with many <fnat>Rutherther: Oh my, the 'fork+exec-command' vs 'make-forkexec-constructor' might have easily just saved me 1h worth of debugging. I was being puzzled by the fact that 'DISPLAY' wasn't picked up despite setting it explicitly as done in the Redshift service. Haha, ty so much. <fnat>It works as expected with 'fork+ex...'. <fnat>I think I see what you say re using a service value as in 'herd start <service> <value>', although it might be better if I first make it consistent with Redshift (and send a patch for that) and then address this other aspect. <luca>Using local-file can I tell it to keep the permissions asigned? At the very least the chmod flags <Rutherther>luca: I think this https://paste.debian.net/1332140/ could be sort of a minimal example of how to change the permissions. Other than that you could make a full fledged package instead of gexp with source being the file <nckhexen>#:recursive? #t, even for single files (if you squint and cross your eyes, permissions are like subattributes). <nckhexen>B…bu…but it's 'documented'®!!! I.e. you have to grep the source and read the docstring. Not great indeed. <nckhexen>(No way you could have known that, really.) <nckhexen>The standard for Guix docstrings is often surprisingly high, it's a pity they don't end up in the manual 'yet'. grepping for define.*foo is often useful, esp. these build helpers. <dariqq>nckhexen: i think in this case the docstring is in the manual, but probably not all are <nckhexen>(But luca, friend, this shows our faith in you reading the docs first—so please do :) <nckhexen>dariqq: I meant 'nope, not all are', most notably the popular guix build utils, not that you were wrong. <nckhexen>I think that's been improved though, so it's fine. <luca>fair enough. If it's intentional that local-file doesn't keep permission bits and you have to use #:recursive #t then so be it <nutcase>a system reconfigure tells me "uix system: error: while setting up the build environment: creating directory `/gnu/store/v4hs8jcqan2mqx4h3y92rpg5dx5g14q0-system.drv.chroot/gnu/store/w0mwibxna4hbh8n8cdx5kinsazbm7w5j-util-macros-1.19.3': No space left on device". Howver my root filesystem has enough free space: https://paste.debian.net/1332144/ What's going on? <dariqq>nutcase: maybe you are out of inodes? Check 'df -i' <nutcase>ok, that could've been a reason: "/dev/nvme0n1p2 61530112 61528784 1328 100% /" (I started guix gc after deleting old generations) <nckhexen>Delete files. Size doesn't matter. Each file (directories are files too) takes up one inode on classical file systems. <nckhexen>File systems like btrfs and bcachefs don't have a limited number of inodes, but that's of little help to you right now. <dariqq>Are you using papirus-icons? I have had inode issues whih them when i had them in system/home profile. Dont know why but when i instead install them with normal 'guix install' things are a lot more sane <nckhexen>Oh yes, that package is nuts. I modified it to use slightly fewer inodes but it's still nuts. <nckhexen>Those look like they are the same bug and should be merged. <dariqq>I think the issue is that for each new system/home profile these symlinks are recreated but not in the guix-install profile <Rutherther>dariqq: my first guess would be that in home profile you have other icons, whereas in guix-profile you don't, so the union tool can make whole share or share/icons a symlink instead of symlinking individually. Maybe it has a certain depth after which it gives up and <nckhexen>It's a pity we can't use hardlinks just for this package (not a serious suggestion but it would fix this issue). <nutcase>although the technical details and how to approach them (e.g. gc triggered by 'out of inodes' or by an upstream fix (if possible at all)) are interesting. What is a good looking alternative? <Rutherther>nutcase: one could also omit few of the resolutions. I suppose you don't use them all <nutcase>Rutherther: would this be an elegant solution? <Rutherther>luca: why exactly? there is the "out-of-source?" flag that will chdir to different folder, specifically ../build from the source. <luca>Because in the archive I am targeting the folder with the makefile I am targeting is in admin/runit-2.1.2/src <Rutherther>oh. So in that case prepending phase before configure that will do chdir could work <old>is gcc-9.5.0 broken? <old>I can't find any substitute, and ci.guix shows that it failed to compile since a long time on core-updates <mccd>Heya, has anyone managed to setup custom userchrome.css directly from their config in Guix? <acrow`>Rutherther: Thank you for the %desktop-services help. I've been trying to add slock to operating-system/privileged-programs but, if I understand you correctly, the right way is instead to tag it as a privileged-programs-service-type. The conflict you mentioned is evident to me too. With coffee I'll check out the parts of the manual I've neglected and get back on it. <Rutherther>acrow`: for screen lockers I would argue the right way is to use screen-locker-service-type. But using privileged programs directly will work as well <acrow`>urg, pre-coffee and not quite literate even in the best of times. Coffee is brewing though -- ack to the above. <Rutherther>old: just submitted a patch #73793 you're welcome to try it and see if it fixes the issue with gcc 9 build <bdju>looks like trying to update to latest yt-dlp release with --with-commit= has a build failure. log if anyone's interested: https://0x0.st/X6vu.txt maybe that's why the package is out of date too. or maybe it's because I haven't updated the rest of my system in a week or two. <gnucode>sneek later tell nckhexen thanks for reaching out! I hope you are having a spooky halloween! There's a really good public domain audio book on the legend of sleeping hollow. librivox.org The best version is the one read by "Chip". <nutcase>Hi, is there a way to list all effective services of my operating-system? <Rutherther>nutcase: I am not sure what you mean by effective, but have you tried guix system extension-graph or guix system shepherd-graph? <gnucode>no freaking way! That was hands down literally the best spooky story I've ever heard! You did a stellar job! <gnucode>grrr... my guix system server is trying to update itself again...guix is making it download mesboot. <gnucode>which sounds like it's building itself from source <chipb>gnucode: sadly, I'm just pulling your leg. <gnucode>chipb: you should go download/listen to said audio book! He's doing wonders for your irc-namesake! <nutcase>Rutherther: guix system extension-graph looks good <nutcase>My intention: I have the impression that I have more services active (that's what I mean with "effective") in my operating-system, than actually needed. Now I want to know, whether it's easier to modify my %desktop-services or to don't include %desktop-services at all <nutcase>maybe, there is another representation that is "easier" (as in "for dummies") to read <bigbookofbug>anyone use elpy? after the latest pull its failing tests for me when i try to reconfigure my system. im not sure if it's something external to the package causing this on my system. it seems that it fails on the emacs-ert dependency for a void "for" variable <bigbookofbug>it fails using `guix build` and `guix shell --container` for me as well, but unsure of how else i can check it to ensure that its not a problem on just my machine <Rutherther>bigbookofbug: builds are in a sandbox, so it shouldn't usually be related to your machine <clarkf>failing tests suggests no substitutes, right? is it possible that the tests are bad? i once had a package that failed to build after 2024-01-01 because the tests had 2023 hardcoded in a few places <krascovict>Hello everyone, how can I help with translations from English to Portuguese? <podiki>bigbookofbug: indeed, tests show as failing on the build farm. perhaps could update elpy as last updated a year ago <podiki>i would suggest trying latest commit <Rutherther>podiki: fails even with latest commit on the same thing <podiki>note that with a transformation i think you lose the patches applied in package definition, though i think that was incorporated upstream now? <Rutherther>podiki: so are you on latest master of guix? the command you sent fails for me on latest guix. There were emacs updates like yesterday, so those could've broken it. <Rutherther>I can build it fine, even gets substituted on guix that is like two weeks old <podiki>from my quick look seems elpy isn't very active? <clarkf>i think much of the community has moved on to LSP-oriented tooling. looks like elpy has been maintainerless since 2021 <kimjetwav>Yeah I've seen a lot of people talk more about other py packages, might have to update my dot emacs again. <kimjetwav>Not a huge fan of py by we use it at work a lot. <clarkf>i've never personally used elpy but i suspect eglot+treesitter will get you most of the functionality <clarkf>once upon a time the only decent python LSP implementation was Microsoft's proprietary one, but i think that's no longer the case <kimjetwav>I should use more treesitter. Elpy does this nice thing where it fires off a separate interpreter for each python env you are running and you can get it to lint your code with a variety of packages like jedi, pep8 etc. <kimjetwav>Helps a lot at work to be able to be like "actually this line in our script fails this stylistic condition". <clarkf>definitely! i think there's a way to plug those tools into flymake <kimjetwav>Yeah, that's how elpy does it. It runs flymake on a separate python interpreter with all the linters and checkers you want it to use. I'd love to get the same thing going with treesit type of functionality. <krascovict>clarkf, ok, I did it... I've already translated 103 lines out of 5,645 <sneek>Welcome back nckhexen, you have 1 message! <sneek>nckhexen, gnucode says: thanks for reaching out! I hope you are having a spooky halloween! There's a really good public domain audio book on the legend of sleeping hollow. librivox.org The best version is the one read by "Chip". <nckhexen>Bit early, I thought, but then it is the 13th, which is extra spookly, and the grandfather clock struck midnight when I read that. So well played. <Guest85>hey guys. can anyone help me with some guix system reconfigure settings? <Guest85>specifically for the "services" field <Guest85>i'm trying to set the authorized keys for ci.guix.gnu and bordeaux.guix.gnu, so i can be able to use it's substitutes <Guest85>however, now that i added it's configuration, i'm having a reported errror as such: guix system: erro: falha ao carregar "~/.config/guix/guix-system-bak.scm": <Guest85>ice-9/read.scm:734:20: In procedure lp: <Guest85>In procedure length: Wrong type argument in position 1: delete <Guest85> (service gnome-desktop-service-type) <krascovict>Guest85, nesse caso é erro de chave, tem que adicionar as chaves do repositório <krascovict>Guest85, é nois... to traduzindo o GUIX pra PTBR <krascovict>Guest85, tem outras pessoas que já traduziram... agpra eu peguei pra traduzir tudo <Guest85>pdc. de repente se precisar de alguma ajuda, tamo ai. Mas so na parte de tradução de inglês mesmo, pq de código eu n manjo nada kkkkkk <krascovict>é bem provável que na próxima atualização já esteja em PTBR <krascovict> i'm trying to set the authorized keys for ci.guix.gnu and bordeaux.guix.gnu, so i can be able to use it's substitutes <Guest85>aqui, sobre as chaves que tu comentou, não estão sendo setadas ali na config? <krascovict>as chaves ficam listadas em .guix-authorizations <Guest85>eu tinha rodado o comando por exemplo "guix weather guix" e ele comentava pra adicionar essas configs no meu arquivo de configuração no campo (authorized keys)