IRC channel logs

<acrow>env | grep XDG

<acrow>I'm trying to run a nncp as a user under local shepherd. Local shepherd wants to run using /run/user/$UID, as you would expect. The problem is that guix intentionally is running headless and so has no %desktop-services. Among a likely long cast of possible solutions is to simply install elogind but I've read enough to know that it also needs pam_elogind and that it does not work for virtual terminals. The experiment might kill this

<acrow>machine. Can anyone venture to honestly tell me it is as easy as installing the elogind package and then, maybe, running 'loginctl'?

<scrambler>Can you dumb down what you're asking for me? If you just want me to run a few commands to try something id be happy to

<scrambler>maybe im misinterpreting you

<scrambler>if you want me to install elogind as a system package and then run loginctl, and that's it, I can handle trying to do that

<acrow>Sure. On a system without %desktop services (headless) can the elogind package be installed and run?

<acrow>At the bottom of it all I just would like to see /run/user/$UID created on login and deleted on session logout

<scrambler>sorry i dont think i know enough to be of any help, i thought you wanted to have someone run a few commands

<ieure>acrow, Yes, elogind works fine on machines without a GUI. I run it on one.

<acrow>scrambler, ieure: thank you.

<vagrantc>(services elogind-service-type)

<vagrantc>works on my mnt/reform, which has some GUI stuff, but by default just logs into the console (which is how i do all my machines)

<acrow>ieure: So, I just install the package (there is no service..) run loginctl and it will initialize itself and pam_elogind will work as expected?

<mra>vagrantc: ooh, an mnt reform???

<vagrantc>and also does not pull in all of %desktop-services ... which can be a lot of stuff to compile that i don't want anyways

<vagrantc>mra: there are at least two pull requests regarding the mnt/reform right now ...

<vagrantc>but yeah, it works reasonably well, even though the substitute servers are sometimes lagging quite a bit ... 8 moderate speed cores and 32gb of ram and NVMe ... makes it workable even to compile fairly big things

<acrow>vagrantc: thanks.. I somehow missed that.

<mra>vagrantc: that's exciting! I've been agonising over whether or not to pick up the Reform Next

<mra>it's so cool, but I already have a perfectly good laptop

<mra>the substitutes are lacking because it's ARM?

<jackhill>any thoughts on GDM not starting in Wayland mode even with (wayland? #t) after the recent GNOME updates?

<vagrantc>mra: yeah, aarch64-linux substitutes are often lagging ... and more often people introduce bugs that fail to build, as they mostly test on x86_64-linux

<apteryx>would someone know the qemu CLI incantation to share a USB device in a 'guix system vm' ?

<apteryx>-device usb-host,hostbus=[bus number],hostaddr=[device number] apparently

<apteryx>with the details retrieved from 'lsusb'

<jackhill>I found https://codeberg.org/guix/guix/issues/3399 but I don't know if that's what I'm experiencing or not (unclear to me from the voluminous GDM debug logs) I do know if the wayland session fails to start up for some reason, GDM will fall back to x11

<apteryx>this gives: qemu-system-x86_64: -device usb-host,hostbus=6,hostaddr=4: No 'usb-bus' bus found for device 'usb-host'

<apteryx>ACTION tries to find something in the 'info qemu' soup

<ieure>acrow, You need elogind-service-type in your operating-system configuration.

<FuncProgLinux>I've already asked in #emacs but I'll give it a try here. How is it possible to debug an error that cannot be catched at early-init.el? :/

<ieure>FuncProgLinux, Does `emacs -Q' work?

<FuncProgLinux>ieure: Yes. It does without issues

<ieure>FuncProgLinux, I recommend launching it that way, then opening init.el and bisecting it. Mark the top half of the file, M-x eval-region. Repeat until you find the problem.

<ieure>FuncProgLinux, FWIW, I've been using Emacs over 25 years and the init debug stuff has never once helped me even slightly.

<ieure>FuncProgLinux, But bisecting by manually evaluating init.el has a 100% success rate. :)

<FuncProgLinux>ieure: I know, I follow your Emacs weirdware org. I'm actually grateful you stepped in to help me :) I'm totaly blindfolded without being able to see any logs or anything. If I have the gc tuning hack in both the early-init.el and init.el file I could suppose those won't apply to my file?

<FuncProgLinux>s/my file/the manual eval of init.el?

<FuncProgLinux>I find it extremely weird because it works fine on my desktop. But I recently installed guix on a new laptop and emacs just refuses to properly work with my configuration there.

<ieure>FuncProgLinux, If you eval the parts of your init files that have the GC tuning, the GC tuning will be applied.

<FuncProgLinux>ieure: I know know it's one of my separate files. But now I don't know what to conclude. Does emacs prefer ~/.config/emacs/elpa/ over the guix packages?

<acrow>ieure: The default elogind-service-type config doesn't suspend or hibernate by default if no one is logged in?

<acrow>ieure: Which would be good for a server.

<FuncProgLinux>Oh well...It may be a good excuse to rewrite and polish this config

<FuncProgLinux>without wanting to be divisive. what do you think is a good choice of a package manager? I've been using package.el for years but have seen people fly with elpaca or straight.el...any recommends?

<ieure>FuncProgLinux, Which location Emacs prefers depends on the value of `load-path'.

<ieure>FuncProgLinux, I've been using Guix Home to manage my Emacs packages since I switched to Guix system, and use-package to configure them. I don't care for package.el. I used straight.el before Guix Home, I liked it better than package.el, but it's very fiddly in my experience.

<FuncProgLinux>ieure: I'm also using guix home before reconfiguring I can "eval-region" to test if I'm going to break things or not. If I made a mistake I can just restart emacs and "nothing happened here"

<FuncProgLinux>I'm basically re-writing my config at this point. Maybe I should just stop obsessing with doom-emacs / spacemacs and go with evil-mode and figure the missing bits out as I need those.

<scrambler>FuncProgLinux I have done something very similar, stopped using doom emacs and went to an init.el with guix. guix takes care of the emacs packages. i am very happy with the result, although i dont have the full functionality of doom yet. I suspect there is a way with guix to install packages so that you don't even need to create use-package stanzas for them.

<ieure>FuncProgLinux, Vanilla Emacs + personal customizations works great for me. I think the Emacs distros are great for getting new users up to speed, but I think many long-term Emacs users end up rolling their own.

<ieure>But that might just be because I do that and it seems logical, so why wouldn't everyone else?

<scrambler>I think that Doom -> emacs guix is much easier than Doom -> general/straight/melpa/whatever Emacs because everything about installing packages is abstracted away. You literally just add the name of the package to a list, and then guix home reconfigure home.scm, then your packages are installed and available.

<FuncProgLinux>ieure: I ended up doing that because one doom update broke my config and while re-doing things myself realized...wait...I don't need a dashboard or other addons

<FuncProgLinux>I'm not an expert but I do like Emacs. Besides librewolf it's the only thing that I don't ever close once opened

<scrambler>plus a dashboard is only 30 lines of elisp and installing emacs-dashboard

<scrambler>i think all of the doom emacs functionality i lost is moments away from me getting back, just have to add their package to the manifest and mayve use-package

<ieure>FuncProgLinux, Agree. I run EXWM on my personal machines. All Emacs, all the time.

<ieure>If Emacs isn't running, the computer's off.

<hunter> What do I need to do to change my shell to zsh? I tried putting `(shell (file-append zsh "/bin/zsh"))` in my user-account in /etc/config.scm but of course it doesn't source any of the path stuff in /etc/profile. Am I doing something wrong or do I just need to manufally copy it to /etc/zprofile?

<FuncProgLinux>ieure: I can see how Guix fits there and makes it a true EmacsOS

<ieure>FuncProgLinux, It's the only distro I know of with EXWM as a first-class option. Big fan of Emacs, but I wish it had a better Lisp, and the whole computer was made of it.

<FuncProgLinux>hunter: I don't know if this helps much but I had to manually create my .bashrc to source such things in /etc I used to have oh-my-bash but I wasn't well aware of how could I link that to guix

<FuncProgLinux>ieure: It is! I was suprised because it's strange when distros offer window managers as first-class options. Let alone EXWM. I just liked the first-class citizen Emacs status and that treesitter "just works" something I ended up giving up on my previous distribution

<hunter>FuncProgLinux Ah I'm using something similar (zprezto) so I'll try messing with it, thank you.

<FuncProgLinux>hunter: I think you could do a simple home service linking the directory and setting #:recursive? #t to keep the excecutable bit on your files if your framework goes for the "shebang" route.

<ieure>FuncProgLinux, tree-sitter is so easy on Guix.

<ieure>I unfortunately have a Mac for work, tree-sitter is very irksome to make work.

<FuncProgLinux>I was allowed to install Gnu/Linux on my machine...unfortunately It's not a distro I really like :/

<apteryx>do we have something similar to guix-pretty-mode, but that actually rewrites the strings?

<Rutherther>sneek: later tell acrow, I am not sure if someone properly addressed your problem. The /run/user/$USER is created by the pam rule, so no, you cannot install elogind as package and get that folder. But you dont need elogind in the first place. You can just set XDG_RUNTIME_DIR to a directory you prefer. People commonly use a directory under /tmp if they dont have logind. If shepherd is started with this env var, it will put its socket there.

<sneek>Got it.

<apteryx>re my earlier qemu usb device passthrough problem; I was missing 1) a -usb, as in "-usb -device usb-host,hostbus=006,hostaddr=004" and 2) I needed to run qemu-system-x86_64 as root for it to have the necessary rights to read the host usb device

<kestrelwx>Morning!

<jlicht>hello guix

<allana>hi #guix, I submitted a patch a some years ago and it was promptly accepted. I realized shortly after that there was a mistake in the package definition and submitted a patch that was never acted upon. I recently issued a merge request on codeberg and a user has reviewed it. I am wondering if it can get some traction by mentionig it here. It can be found here: https://codeberg.org/guix/guix/pulls/3354

<allana>Basically it has a flaw when substituting paths in the package source with paths to store inputs. It's very obviously broken in its current state.

<allana>I also wrote an issue before creating the merge request: https://codeberg.org/guix/guix/issues/3353

<jlicht>allana: I might be misunderstanding things here, shouldn't the entire phase not be needed here?

<Deltafire>i was just thinking the same

<allana>At runtime vpn-slice executes ip and iptables, and they are hardcoded in the original source as "/sbin/ip" and "/sbin/iptables". The phase patches those sources to point to the store paths

<Deltafire>but why change the substitution from /sbin/ip to '/sbin/ip'? it makes no difference

<allana>And in the original patch I provided the "/sbin/ip" substitution clobbers the "/sbin/iptables" string in the source

<Deltafire>ah, ok

<allana>so we end up with something like "/gnu/store/c3fa94c62chbj42q905zfi33x7z7kr9m-iptables-1.8.11/gnu/store/63ag845bnjj5ff674sv92winaxsxrcjw-iproute2-6.4.0/sbin/iptables" in the source, which is wrong

<jlicht>allana: got it now as well :-)

<kestrelwx>Couldn't you just match the single quote after "ip" then?

<jlicht>allana: after working on my team branch, I'll have a quick look and if it builds, merge it

<allana>kestrelwx: sure! I'm sure there are better ways to match. This is just how it made most sense to me at the time. I have been sitting on this for a while

<allana>jlicht: thanks.

<jlicht>allana: just to double check, you've verified it works for you with your changes applied?

<allana>jlicht: yes, and I have been using it for a long time. I will double check though, it would be a shame if it didn't

<allana>jlicht: yes, it looks correct.

<flypaper`>hey, made a pullreq updating apertium, a dictionary tool, at https://codeberg.org/guix/guix/pulls/3443, first time comitting on codeberg and i dont think it falls under a team, the CI approved it, could someone have a look?

<flypaper`>s/approved/succesfully built

<Deltafire>how does a commit get assigned to a team? is it automated?

<Deltafire>seems like if it's not assigned, it just sits there

<mra>Deltafire: i'm pretty sure that someone has to manually assign it

<mra>how long has your PR been sitting around? sometimes it just takes a while

<flypaper`>think i submitted it thursday evening.

<look>Deltafire: team assignment is automated, and is done per-file. See 'etc/teams.scm' (L446-1040). Also check the CODEOWNERS file in the root dir

<mra>oh, weird. in the history of my current PR it shows Ludo manually assigning it to a team.

<luca>yeah should be automatic. slow typer, but here's the source https://forgejo.org/docs/latest/user/pull-requests-and-git-flow/#review-requests-and-code-owners

<flypaper`>(though i once submitted to the old tracker an issue, and nobody ever responded to that, maybe because it was a long one)

<look>If the file you're editing is not listed in etc/teams.scm (or CODEOWNERS) it won't be assigned automatically to any team

<mra>flypaper`: responses can just be slow. it's not a huge team, and they get a lot of pull requests and issues

<look>This is the case with #3443, for example (the dictionaries and textutils modules do not belong to any team atm)

<mra>i've been waiting for a few days for someone to look at my PR. that's kinda just how it is, i think

<mra>look: ooh, okay. good to know! maybe my automatic assignment was delayed because my PR was originally marked WIP

<flypaper`>whats a good policy of waiting / when is it okay to send a ping?

<mra>currently asking myself the same thing lol

<look>It should assign a team automatically after you remove the WIP tag

<look>If someone manually gives it the right team while its WIP, then it wont assign the team when the WIP gets removed, because the team was already manually assigned

<mra>look: yeah, i think that's what happened

<ekaitz>flypaper` & mra send me the pr numbers please and I'll try to take a look (i can't promise anything)

<mra>ekaitz: oh, no worries. Maxim and Ludo both know that my PR exists, they just haven't had time to look at it, I assume

<mra>it's 3369 if you're interested, but don't feel the need to look at it unless you're interested

<look>I generally send a ping to the last person who worked/commited the package in the commit history when its fully ready for review

<Deltafire>maybe we need a team for when there's no team!

<ekaitz>mra: great got it

<ekaitz>probably it's better that they review it

<Deltafire>i've got a nice easy one to merge, it's just one line: https://codeberg.org/guix/guix/pulls/3439

<mra>ekaitz: yeah, I reckon so. it was an interesting change to develop! I hope it works

<flypaper`>ekaitz: 3443 , but now i noticed that `guix lint` had some complaints about whitespace, so lemme fix those.

<jlicht>allana: merged, thanks for the fix!

<ekaitz>flypaper`: git push --force for the win, ill take a look to it later

<flypaper`>ekaitz: fixed now, see #3443 https://codeberg.org/guix/guix/pulls/3443 , no rebuild happened when `./pre-inst-env -k -P1`

<flypaper`>ekaitz: (theres one line that `guix lint` complains about being too long, but i think that one is within style, because its a long regexp in a substitute* macro, which would make it less readable splitting it. )

<Phosphenius>Hi, is there support for VCS packages in Guix? I’ve followed the instructions from the cookbook to set up a development environment with a package definition inside the repo.

<Phosphenius>Is there any way to get the current version from git or do I have to set a new version by hand for each commit that I want to build for?

<flypaper`>ekaitz: also, whats easier for maintainers? I have in my packaged a translating dictionary for apertium, but its for getting there it has 6 other packages, should i submit each of those separately or as one PR ?

<Rutherther>Phosphenius: when packaging sw through guix, you don't have access to the .git anymore inside the build. So you have to do that manually

<flypaper`>Phosphenius: if you mean 'how do i get the latest upstream version of a software with guix on my machine right now', you can use e.g. `guix shell nano --with-latest=nano`

<flypaper`>if you mean, 'how do i automatically update package definition in the guix source tree to be have the version thats the latest in upstream', you can use `./pre-inst-env guix refresh nano`

<Phosphenius>Rutherther: Thank you, I see. So I cannot build a package for every commit without specifying a version for each commit?

<Phosphenius>flypaper: No, I mean I have a package definition in my repo and I would like to build the package for each new commit. But I cannot, without changing the version number manually: https://codeberg.org/Phosphenius/bomdia/src/branch/main/.guix/modules/bomdia-package.scm#L26

<Phosphenius>Arch Linux™ has this concept of “VCS Packages”. I really liked that and looking for a way to do this with Guix now. (I’m a new Guix user, recently coming from Arch)

<flypaper`>Phosphenius: i guess you could write some code with guile-git that looks at your repo, and gets your list of commits, and then makes a variant of each package with those commits

<Rutherther>Phosphenius: since you're using local-file, the version you put in version doesn't matter. What you have checked out locally is what matters

<flypaper`>but the user can always do 'guix build --with-commit=bomdia=deadbeef` if they want to use commit `deadbeaf`, so theres no need for you as a packager to supply it, if theres nothing 'special' about that commit

<Phosphenius>flypaper: I take it that is similar to how `gash` does it? https://codeberg.org/civodul/gash/src/branch/master/guix.scm#L32 Seems like a lot of work though …

<Phosphenius>Rutherther: But it does not build a new package if one exists with that version number, no?

<Rutherther>Phosphenius: it definitely should, the version number doesn't matter

<Phosphenius>flypaper`: OK, that seems like a workaroud I could live with. :) How come this is not documented though? `guix build -h | grep -i commit` does not yield anything. ^^

<flypaper`>Phosphenius: thats because its a `transformation` and its listed under `guix build --help-transform`

<flypaper`>see also "info "(guix) Package Transformation Options"

<Rutherther>Transformation with commit will not work here though, because the source is not an origin with git-fetch, but local-source

<Phosphenius>Rutherther: You’re right, it builds locally from the repo, but I’ve also set up the repo as a channel …

<flypaper`>Phosphenius: yeah so as long as you have the local-file, you specify which commit to build on in your channels file

<Phosphenius>Wait, does the fact, that it uses local-source explain, why the package build from the channel is empty?

<Rutherther>Phosphenius: depends on what you have in the channel. If repo with the package is also a channel and it uses local file, always the current source will be used. No need to change version

<flypaper`>Phosphenius: hmm, that shouldn't be the the case. I think guix is expecting "project.console_scripts" or "project.gui_scripts" rather than project.scripts

<flypaper`>Phosphenius: hmm, though that also doesnt seem to include anything

<Phosphenius>flypaper`: It does work when built directly from the repo though.

<Phosphenius>I also have a package definition in a local channel with git-fetch as source and it also works fine.

<Phosphenius>Rutherther: it is also a channel. I followed the cookbook for this.

<Rutherther>Phosphenius: in that case the culprit might be the relative path, sometimes local file chooses the wrong base. You might want to use (current-filename) and base it off of that, ie. (string-append (dirname (current-filename)) "../../")

<Phosphenius>Rutherther: Thanks, I’ll try that. The Shepherd source does is similarly: https://codeberg.org/shepherd/shepherd/src/branch/main/.guix/modules/shepherd-package.scm#L60

<flypaper`>Phosphenius: yeah, that might be pointing to the right thing, because when i add an error after the build phase and then build with --keep-failed, i see theres nothing of the source there.

<Phosphenius>But how con guix distinguish packages with the same name and version? Because I have a bunch of broken/empyt packages in my store which I don’t seem to be able to remove and when I install a package, it’s always a broken one …

<Phosphenius>*can

<flypaper`>guix itself distinguishes packages by its inputs (that is to say, source shasum, dependencies recursively, and including its build side instructionm, the derivation). If those are different then for guix they are different packages. thats this hash you see at the front of a package path. but then when you specify a package to install on the cli, you use the _specification_, which is packagename@version where version might also be

<flypaper`>something in the style of version-revision-commit as is common.

<flypaper`>`guix gc` should remove packages that have nothing else pointing to them, if you have problems removing them you can use `guix gc --referrers /gnu/store/shasum-bombdia*/` to see whats keeping it alive

<flypaper`>`guix gc --clear-failures` will builds that exited with a zero-exit state, and you could do e.g. `guix gc -D /gnu/store/*bomdia*` to only remove 'dead' bomdia directories, but keep your rest the same

<Phosphenius>Yeah I tried to remove/gc them yesterday, but I guess some are kept alive by previous generations or something. ^^

<flypaper`>(and just `guix gc` will clear as much space as it can)

<flypaper`>did you e.g. do a `guix shell -f guix.scm` ?

<Phosphenius>Thanks flypaper` and Rutherther, that def. helped me. ^^

<flypaper`>or a `guix install -f guix.scm` ?

<Phosphenius>flypaper`: Yeah, I use that `guix shell` for development. I didn’t do `guix install -f` though AFAIK.

<flypaper`>yeah, then in /var/guix/profiles/per-user/$USER/profiles there would be symlinks to profiles that can contain those references, you can either all of those if you none of your shell caches are important, or you can crossreference them the targets of those symlinks with the result of `guix gc --referrers /gnu/store/*bomdia*`, and unlink those that are in pointing list. after one of these two

<flypaper`>fl

<flypaper`>Phosphenius: (ignore the fl) apperently to the doc, those would be removed after a certain alive some time with `guix gc`, but its always stays too long imho.

<flypaper`>so removing the symlinks keeping them alive is the way to get rid of them.

<Phosphenius>OK, but this will not really solve my problem because if I keep building from the repo with a fixed version string, more and more packages with the same specification will pile up, right?

<Rutherther>Phosphenius: no, if the source is different, it is a different package

<ekaitz>flypaper`: we add one package per commit, but you can do all of them in the same PR if you wish

<Phosphenius>Rutherther: But there’ll be no way to tell them apart, correct? Like when I do `guix install $package@$version` how can it tell which package is meant when they all have the same $version? Or am I missing something here? ^^

<Rutherther>Phosphenius: Guix install will only see the latest one in the channel, it doesnt know about the other ones. Though you are right that I am not sure if it will decide to reinstall, not sure if that is based off of the version or not

<Rutherther>What is built in the store doesnt concern guix install. It is concerned only with packages in current guix channels you are using

<flypaper`>ekaitz: (also, i think CI finished and noticed there was nothing to do, but the bot didnt post anything because there were no packages that changed https://pulls.ci.guix.gnu.org/eval/2082 )

<Phosphenius>Rutherther: Ah, that makes sense—thank you. :) Unfortunately, the build from the channel is still empty.

<ekaitz>I got a question for commiters-maintainers: are you doing anything special to add traceability to the commits? do you add the PR id in the commit or something like that? There is traceability with the Change-Id from the PR to the commit, but how easy is to do the opposite?

<flypaper`>Phosphenius: I get it to put thing in bin since 6bc82aa , both with `guix build -f guix.scm` and with the channels

<Phosphenius>flypaper`: It still doesn’t work with the channel for me … :/

<flypaper`>my channels file looks like this: https://dpaste.org/36d4R

<flypaper`>i've also had success in the past if vcs-file? looks like this: https://dpaste.org/qjQ6g

<ekaitz>flypaper`: I sent you some comments in the PR, some simple stuff

<flypaper`>ekaitz: thanks! saw them!

<ekaitz>flypaper`: if you need anything ping me here, I don't think I'll remember your codeberg nickname <--> irc nickname mapping

<kestrelwx>Is `git-repo-go` complete or abandoned?

<kestrelwx>Oh, ours is from apteryx.

<Phosphenius>flypaper`: Thanks again for your help. :) It still doesn’t work for me, although I have not tested the vcs-file? changes yet. How come building from the channel works for you but not for me?

<Rutherther>Phosphenius: but wait, your channel is only under that .guix/modules, I havent realized that. That means that relative to the channel there is a random folder, not your repo. Also at the point it is a channel, it is no longer a git repo. I think you will have to use something else than local file to fetch the source.

<flypaper`>ekaitz: addressed the issues! added a comment in the thread, and built everything locally again and guix lint is happy.

<flypaper`>ACTION is becoming rapidly familiar with magits rebase interface

<ekaitz>okay let me see

<flypaper`>also, a philosophy style question, can a package expect its own /bin/ to be in the path?

<flypaper`>because i was substitut*ing things in the apertium shell entry script that was expecting to be in the path with the store refences to the packages, so that we'd have proper references, but not its own programs. Should I ?

<Phosphenius>Rutherther: I don’t understand. I followed the cookbook on this … So I cannot use local-file?

<flypaper`>Phosphenius: Can you share your channels file?

<Rutherther>Phosphenius: It seems to me the cookbook is wrong here. But I am not sure and cannot check now

<Phosphenius>flypaper`: like my configuration in .config/guix/channels.scm?

<Phosphenius> https://dpaste.org/USjyX

<flypaper`>like in `guix describe -f channels`; or in other words, how exactly do you test this? I was testing it with `guix time-machine -C channels.scm -- build bomdia` with channels.scm being the contents of https://dpaste.org/36d4R

<flypaper`>(yeah with the link you sent i didnt have your guix, which is what i wanted so i could get the same setup)

<Phosphenius>Sorry, here is the `guix describe -f channels` outpout: https://dpaste.org/wjpMb

<flypaper`>thanks! building now

<flypaper`>is the result of `guix build bomdia` for you /gnu/store/f55iwinzfwylz1kvrbjv2qmmk41s4bsa-bomdia-0.1.0-git ?

<flypaper`>with exactly that hash?

<flypaper`>ah, can you do `guix build --source bomdia`

<flypaper`>whats the result of that for you?

<flypaper`>ekaitz: the CI builder finished again, derivations stayed the same.

<ekaitz>flypaper`: about the inheritance, you can overwrite all arguments so the build process is just different

<Rutherther>Phosphenius: when you look in the built channels output, ie ~/.config/guix/current if you pulled or the output of "guix time-machine -C channels.scm", you will notice your package file under "share/guile/site/3.0". And if you navigate 2 levels up from it, you will be in share/guile. This folder is not a git repository and also doesn't contain any sources of your package. So I am pretty sure that's the reason for getting empty output

<flypaper`>ekaitz: yeah, thats the case now.

<flypaper`>ekaitz: also overwrote native-inputs to be explicitly the empty list, because ftest was not a dep yet.

<Phosphenius>flypaper`: I only tried building it with `guix pull` followed by `guix build bomdia`. I don’t have that exact hash on my system. `ls -lah /gnu/store/f55*` yields nothing. The result of the build with `--source` is an exception: Throw to key `match-error' with args `("match" "no matching pattern" "/gnu/store/gqng4irn7jmd5ac3zxi7mmlpm9rdycgh-bomdia-checkout")'.

<flypaper`>and when you navigate to /gnu/store/gqng4irn7jmd5ac3zxi7mmlpm9rdycgh-bomdia-checkout it is empty?

<flypaper`>Rutherther: the odd thing is though, he is following exactly the pattern of shepherds-repo-as-a-package+channel

<Phosphenius>Not entirely; it’s got a site/ dir with some symlinks.

<flypaper`>but nothing that looks like your source

<flypaper`>?

<flypaper`>what if you `guix gc -D /gnu/store/gqng4irn7jmd5ac3zxi7mmlpm9rdycgh-bomdia-checkout` and try again?

<flypaper`>because sometimes `local-file` is kinda lazy

<flypaper`>with try again i mean, `guix build bomdia`

<Phosphenius>No, the symlinks are not my source, some are *.scm and the all seem very gnu and guix related. ^^

<Phosphenius>flypaper`: No news, gc’ing and trying again didn’t change anything.

<Phosphenius>I could try renaming the checkout …

<flypaper`>did that force a rebuild or did it just immediately give you the previously built thing?

<Phosphenius>After the gc’ing? It didn’t rebuild.

<flypaper`>try `guix build --check bomddia` and also pay attention to what it says in the unpack phase?

<flypaper`>(--check forces a rebuild)

<Phosphenius>One sec, `guix pull` is still doing it’s thing.

<mra>hm, just saw the call put out for new core team members

<Rutherther>flypaper`: I know it's the same approach as shepherd and tbh I don't know how that works. I suspected substitutes, but it seems even with substitutes disabled it somehow works. The channel source is still in the store, but I do not know how local-file could know the original location of the file

<Rutherther>maybe it's somehow supposed to work, but I don't really see how it could

<Phosphenius>flypaper`: nothing changed.

<Rutherther>but it also works for me so I must just be missing something

<Phosphenius>Rutherther: Huh, you can successfully build from the channel as well?

<Phosphenius>flypaper`: It links the sources wrong: https://dpaste.org/Nputk

<flypaper`>Phosphenius: thats _very_ odd

<kestrelwx>sneek: later tell efraim Did you try an ything yet with nouveau? And could you confirm if this https://gitlab.gnome.org/ gives "Oh noes" in Qutebrowser?

<Rutherther>Phosphenius: yes

<sneek>Okay.

<Phosphenius>flypaper`: I built it with a different user and now it workes. Is my profile borked somehow?

<Phosphenius>I used the exact same channel configuration.

<flypaper`>so yeah, i'd say do `rm /var/guix/profiles/per-user/$USER/profiles/*; guix gc; guix build bomdia`, because somehow guix remembered and doesnt want forget the wrong source, and its being kept alive by some of your guix shell profiles

<flypaper`>hmm, thats weird.

<Phosphenius>Yeah that didn’t fix it … ^^

<Phosphenius>It did not rebuild.

<flypaper`>how long is the list of `guix gc --referrers $(guix build bombdia)` ?

<Phosphenius>It throws an error: guix build: error: bombdia: unknown package

<flypaper`>ehh typo, should be bondia, no explosives intended

<Phosphenius>Oh, LOL, didn’t notice.

<Phosphenius>It’s just one profile item.

<Phosphenius>How do I find that profile? I seem to have so many. ^^

<flypaper`>if you do `guix gc --list-roots | xargs ls -lta`

<flypaper`>and then searhc for that one

<flypaper`>so in one command `guix gc --list-roots | xargs ls -lta | grep "$(guix gc --referrers $(guix build bondia))" -`

<flypaper`>here in a pastebin if your client screw this up: https://dpaste.org/tvjNg

<Phosphenius>You misspelled it again. :P

<Phosphenius>In any case, I’ve found the profile(-link).

<flypaper`>yeah so if you rm/unlink that link that link, then `guix gc` is free to remove anything that was previously keept alive by only that root.

<flypaper`>where is it located?

<Phosphenius>/var/guix/profiles/per-user/user/guix-profile-92-link

<Phosphenius>Can I safely unlink that?

<flypaper`>so you got it with a `guix install`

<flypaper`>when you `guix package --list-generations` ?

<Phosphenius>The most recent is 93

<Phosphenius>WTF, gen. 92 is from a later time than gen. 93.

<flypaper`>how do you mean?

<flypaper`>the mtime?

<flypaper`>ah hby the output from list-generations?

<Phosphenius>I copied (some) of the output here: https://dpaste.org/QgvdD

<flypaper`>thats odd

<flypaper`>i know that guix has a time-machine, but apparently you're a timetraveller :P

<Phosphenius>xD

<flypaper`>anyway `guix package --delete-generations`

<Phosphenius>Why is everything weird with my system? It’s only a few weeks old _at most_

<flypaper`>that should remove all but the last one

<Phosphenius>OK, gc’ing now.

<flypaper`>as in all but 93 93

<flypaper`>^ note this is guix package subcommand rather that guix gc

<flypaper`>(still `guix gc` after that)

<Phosphenius>yeah, I meant I’m running `guix gc` ^^

<Phosphenius>Argh, still the same issue …

<flypaper`>did it rebuild at least?

<Phosphenius>Yes

<flypaper`>okay, so we did manage to get all the references gone, thats good. Btw, did you one time maybe do a guix pull but with your own channel name field but with url of the guix channel or the shepherd channel ?

<Phosphenius>I don’t think so …

<Phosphenius>I think with the channel intro possibly. I copied but forgot the change the fields.

<Phosphenius>Should I remove my channel?

<flypaper`>a silly solution would be to rename "bomdia-checkout" to something, e.g. "bomda-source" so that the storepath is forced to be different

<Phosphenius>I already did that, I renamed it to bomdia-checkout-git. But I can try again.

<Rutherther>Phosphenius: have you tried adding the shepherd channel and building shepherd@1.0.99-git?

<Phosphenius>Rutherther, nope, but I can build my package with a different user on the same host.

<Phosphenius>It does the exact same thing with a new checkout name …

<flypaper`>okay, i'm stumped, and got to make dinner, so have a good night : )

<mgd>Is there a way to remove generations created after the one you are on? I have had to go back because of issues with a newer generation

<Rutherther>mgd: the only generation you cannot touch is the current. Just run delete generations with the gen number you want to delete

<FuncProgLinux>If someone has some spare time can you please provide feedback on https://codeberg.org/guix/guix/pulls/3199 ? I closed it because I thought the git hooks broke but it was a false alarm

<Phosphenius>flypaper`: Thank you (and Rutherther) for your help again. Learned a lot today. ^^ I’ve deleted all generations (of guix packages and guix pull), for all relevant users, gc’ed every trace of the package from the store and deleted .cache/*. The problem persists.

<flypaper`>Phosphenius: glad to help :)

<Phosphenius>I tried building the shepherd in the same way: same error.

<Rutherther>Phosphenius: okay great! So it's a 'setup' error, nothing is wrong with your channel

<Phosphenius>It even seems to link to the same source.

<gabber>don't we have some cloud-style file collaboration software (like nextcloud or seafile) for guix?

<Rutherther>Phosphenius: same source as what?

<euouae>Hello all, when you want to specify compile and warning flags for your guile projects, what variables are used in Guix?

<euouae>I don't think Guile specifies any standard one's (or does it?)

<Phosphenius>Rutherther: both my package (bomdia) and the shepherd have the wrong source when trying to build.

<Phosphenius>It links to some files belonging to Guile …

<Rutherther>Phosphenius: I get that, but are you saying it's the same source? how did you figure that out? The name should be different - shepherd-checkout vs bomdia-checkout or something like that

<Phosphenius>It looks very similar. ^^

<Rutherther>can you send the build log?

<Phosphenius>Let my take a look …

<Phosphenius>Shepherd build log: https://dpaste.org/OcF3t

<Phosphenius>Rutherther: I ran this: guix build shepherd@1.0.99-git -K

<gabber>gabber: i think syncthing would be what you're looking for

<Rutherther>that's interesting, you're really getting the ../.. from the source of the file. But I am not getting that, I am getting files from the original repository. Tbh the behavior I am getting is the one I am confused about

<Phosphenius>Rutherther: And it works with a different user for me.

<Phosphenius>I seem to be getting files from: .config/guix/current/share/guile/site/3.0/

<Phosphenius>It put the package definitions (those of shepherd and my package) into there. Do you think I can unlink them?

<Rutherther>that is correct. It should put them there

<Rutherther>there is nothing to unlink

<Phosphenius>OK. ^^

<euouae>nevermind foudn it, GUILE_WARNINGS and GUILE_OPTIMIZATIONS

<Phosphenius>Rutherther: I am at my wits end. Should I file this as a bug? I’ve no idea what I set up wrong with my system (or rather user/profile).

<Rutherther>I am not sure. Give me a moment, I am crafting a debugging channel

<Phosphenius>Rutherther: on my user account where it works, I get a cannot access `/home/user/.config/guix/current/share/guile/site/3.0/guix/platforms': Permission denied

<Rutherther>Phosphenius: where /home/user is home of that user? I don't really understand why the user wouldn't have access there

<Rutherther>Phosphenius: I have made sort of a debugging channel here: https://git.ditigal.xyz/~ruther/debugging-channel. Can you clone it, use time machine with the provided channels.scm, ie. "guix time-machine -C channels.scm" and then provide the output of debugging.scm inside of a repl? Ie. "guix time-machine -C channels.scm -- repl debugging.scm"

<Phosphenius>Rutherther: Ah, sorry. No, my main user is just called "user". I can built it with another user called "dev" and for that user, it tries to access the path belonging to "/home/user".

<Phosphenius>I’ll try your channel. :)

<Rutherther>Phosphenius: what exactly tries to access that path? Did you log in as it without using a login shell? Ie. "su dev"? always use "su - dev" to use a login shell

<Rutherther> https://paste.debian.net/1400767/ here is my output, what is particularly important is that local file's absolute path, for me it somehow points to the original source. I suppose for you it will point to the built channel sources

<Phosphenius>Oh, I used just "su dev" …

<Phosphenius>Rutherther: I just logged into the "dev" user with "su - dev" and now the package is empyt there as well.

<Rutherther>Phosphenius: what file system are you using?

<Phosphenius>ext4

<Phosphenius>Rutherther: here’s my output: https://dpaste.org/nm5iM

<Rutherther>Phosphenius: okay and if you look into that /gnu/store/ii6vdlm8f5y4hxxzwdssxvzpirng2c4b-my-source, does it contain hello-world string?

<Phosphenius>Yep

<Rutherther>that's interesting. Now I am even more confused

<Rutherther>I don't understand why this works fine for you, while with your channel / shepherd it doesn't

<Phosphenius>Maybe because of time machine?

<Rutherther>you can try pulling if you want. I would be surprised it would be different

<Rutherther>anyway yeah create a bug report, I am probably not going to figure that out, at least not right now

<Phosphenius>I’ve created an issue for my weird build problem: https://codeberg.org/guix/guix/issues/3523

<FuncProgLinux>Maybe this is a question for #emacs but...when using a single elisp file for init without straight.el or elpaca. The excecution order is from left to right, top to bottom...right?

<scrambler>I hope it is otherwise my mental model is wrong

<mra>FuncProgLinux: i'm not necessarily sure if "left to right, top to bottom" is the clearest way of thinking about it. formally, lisp programs have the structure of trees, right?

<FuncProgLinux>mra: Indeed. So it goes in the same order as S-expressions

<mra>FuncProgLinux: well, i guess the way that i think of it is that it goes kind of like a depth-first search, reducing a redex if it can, or recursively evaluating the argument of the redex if it can't

<Phosphenius>Anyone know where I can get shield.io type badges for Guix? I saw some once on the package browser, so they do exist.

<mra>Phosphenius: https://codeberg.org/guix/artwork/src/branch/master/badges

<Phosphenius>mra: Thanks a lot!

<FuncProgLinux>mra: I was debugging a reproducibility issue I had with my Emacs config. I'm trying to ditch out the "flexible" parts and narrow things down to a box

<mra>FuncProgLinux: how d'you mean?

<FuncProgLinux>mra: I had a file mess that I had to turn into a monolithic init.el file. The configuration problem I had was that, the exact same Emacs configuration was behaving one way on a Guix system, and a completely different way on another machine. What I don't understand is why

<FuncProgLinux>On paper things must be the exact same 1:1 bit-by-bit copy. But I'm also loading files and using hooks. Less dynamic things == Less errors..I think at least lol

<FuncProgLinux>It turns out the guix version of emacs-neotree doesn't work with emacs-nerd-icons :/

<ieure>FuncProgLinux, Customizing Emacs' visual appearance has always seemed highly correlated with stuff breaking in surprising ways. I don't bother with any of it, no icons, color themes, etc etc. I love my fast, capable, ugly editor.

<FuncProgLinux>ieure: I'm about to nuke the neotree package as well :s

<FuncProgLinux>But I did grew used to having a per-project sidebar. Idk if I can achieve that with dired only.

<ieure>FuncProgLinux, Have honestly never understood why people like sidebars. They take up so much screen space and are so slow to use.

<ieure>FuncProgLinux, I use projectile-find-file, will let me open any file in the project from anywhere else in the project.

<ieure>Dired if I have no idea what file I want to open.

<ieure> and/or deadgrep.

<FuncProgLinux>ieure: If I'm honest. idk either, I was used to having two sidebars since my vim days. One for the source-tree of the project I was working on, and one for the symbols. I learned to live without the symbols one

<FuncProgLinux>I used find-file-in-project for quick navigation when I don't remember where a file is. But I also like having a quick file editor at hand on F3 because NerdTree muscle memory

<mra>FuncProgLinux: i just slap a colour scheme on emacs to make it a bit less ugly, but i don't fine-tune much in terms of appearance

<mra>somewhat messy, but here's my emacs config if it's of any help: https://codeberg.org/mra/dotfiles/src/branch/main/emacs/config.org

<FuncProgLinux>mra: Thanks a lot! I'll read it maybe I can improve mine with your knowledge :)

<FuncProgLinux>I'm grateful for receiving configs/code as responses :) thanks as well, for the patience I wish I could learn faster how corn cooks here

IRC channel logs

2025-10-13.log