IRC channel logs


back to list of logs

<ChocolettePalett>Oh, nvm, XHTML seems better than HTML5, I'll try the parser again
<singpolyma>It's not a competition :) xhtml5 is part of HTML5 spec
<cbaines>civodul, no problem :) I still need to get the qa-frontpage to look at the blocking information for the branch issues, but yeah, I think having a clear list will help with speeding up making big changes
<civodul>cbaines: yes, it's really good
<civodul>perhaps we could have a weather icon right on the front page too?
<civodul>and an icon for branches needing a rebase
<cbaines>yeah, that sounds useful
<civodul>great that pages like explain all that!
<civodul>ACTION -> zZz
<reily>I'm having some trouble getting guix home working on a foreign distro with Gnome and GDM, where Gnome and GDM are installed and configured using the foreign distro. Attempting to log in to a Gnome session results in a gray screen for about half a second, and then I get sent back to the login screen without an error message. However, if I login on a terminal and run ~gnome-shell --wayland~, Gnome starts fine. Has anyone else encountered
<reily>this issue? I am aware that some issues have come up with XDG environment variables, but mine seem to be set correctly, and I would think that would impact terminal and GDM launched sessions equally.
<HexMachina>reily: I had an issue like that once that was due to python being installed in my guix profile and it being a different version from the foreign/host distro version. It's a bad idea to install python in your default profile on a foreign distro
<lw>Hello, I'm new to guix. I'm confuse about something. I'm trying to run a `sudo make install` build of st. But, it says I have no harfbuzz installed. I just installed if, although, I can't issue harfbuzz in the shell afterwads. Although, the binary is under /gnu/**/harfbuzz
<zamfofex>I feel like you shouldn’t be using ‘sudo make install’ at all!
<zamfofex>A more Guixy solution is to apply patches to the ‘st’ package and install that. (I use st myself, and that’s what I do.)
<zamfofex>If you’re not using Guix Home, a very simple solution is to install st like this: guix install --with-patch=st=customization.patch st
<lw>Hm, interesting, i just issued `make install` and now it gives i don't have `ctype`, but stopped complaining about harfbuzz
<lw>How would I change the `config.h` of the `st` guix installs?
<zamfofex>You should write a patch file that customizes st to your needs, then apply it with the ‘--with-patch’ option.
<lw>That do make sense to me, but seems a hassle for now (because I'm not proficient with writting patches)
<zamfofex>You can usually use a tool that does that for you!
<lw>Do you think it would be straight foward to take my config.h and write a patch?
<zamfofex>If you have ‘st’ from git, you can write ‘git add . && git diff --staged > my-patch.diff’, then use the generated the ‘my-patch.diff’.
<zamfofex>Otherwise, you can use the ‘diff’ command, but it takes a zillion options (and thus is a bit less straight‐forward to use).
<lw>yeah, unfortunatly, my st is my own repo, and there are no tracks of changes except the head
<lw>I create the repository afterwards, when the build was already complete
<zamfofex>Well, if you cloned st from git (as oppose to, say, from a tarball), the command I wrote above should work: ‘git add . && git diff --staged > my-patch.diff’
<lw>I will try to install the other `ctype` dependency and use `make install` (as it seems using `sudo` makes the command use another foreing environment that doesn't have any packages I installed with guix)
<lw>the patch produced is empty, here
<zamfofex>Ah, did you commit the changes you applied?
<lw>The problem is, this `st` is `BuddhiLW/st`, which is not originated from `official/st`
<lw>So, there is "no changes"
<zamfofex>Ah, I see. You can use the ‘guix install --with-source=st=’, then. But if it has an additional dependency, you also have to specify it.
<zamfofex>Sorry, I mean: guix install --with-source=st= st
<lw>amazing, I will try this one
<zamfofex>Hmm, perhaps ‘--with-git-url’ is the actually correct one.
<zamfofex>Note that it’s not usually sensible to want to mix Guix packages with ‘sudo make install’ like you wanted. I wouldn’t say “impossible”, but it’s probably going to give you a lot of trouble overall.
<lw>I'm ok with `make install`
<lw>Is that version ok?
<zamfofex>Well, I mean that you can’t easily get it to “see” your Guix packages.
<lw>The commands gave error: `with-git-url=st=https: unknown package``
<lw>It's a bit late around here. I will git another shot tomorrow, or just try doing the patch stuff, and rewrite the changes from the fresh st
<lw>Thanks for the help zamfofex
<zamfofex>Sure, I hope you can get everything to work out in the end!
<lw>Well, I will make it work out, as we engineers do, right? I'm eager to adopt guix as my system, and that's decided for now haha
<lw>always a pleasure to feel a noob, and learn a lot
<lw>See you
<adanska>Hey guys! I'm trying to add gdm with wayland support to my config, but gdm is already defined as a service in %desktop-services. What is the best way to redefine gdm in my services configuration?
<civodul>Hello Guix!
<al1r4d>civodul: hello
<cbaines>woo, the testing is happening for
<civodul>cbaines: yay!
<civodul>though many of the Fibers-using packages lack good test suite coverage
<civodul>but as long as shepherd passes, we should be good :-)
<civodul>ACTION attempts a 'guix' package upgrade, for the various "guix substitute" fixes
<civodul>cbaines: is looking much better: the Julia issue on i686 turned out to be flaky tests
<civodul>so we're left with the qgis test failure on x86_64, which i suspect is due to flaky tests as well
<cbaines>civodul, cool, it's good to know that julia isn't broken
<cbaines>personally I think it's OK to merge, at least we know that something may be up with qgis
<civodul>cbaines: yeah, i guess i'll push it and monitor to see if qgis eventually builds...
<evilsetg[m]>adanksa: I would use `modify-services` on `%base-services` like this:
<cbaines>civodul, /gnu/store/npjr640n7l1w9l1zkpx9w8ljias1gl5x-qgis-3.30.1.drv builds for me locally
<evilsetg[m]> whoops, I meant to address you above but I misspelled your your name.
<lurdan[m]>hi, I'm trying guix home environment with guix binary installed on debian bullseye, and have some question.
<Guest99>Evolution in guix is outdated by like a year. Where can I submit request to have it updated? Guix version is 3.46 while upstream is 3.48.
<lurdan[m]>I found there are 3 types of guix profile, current-guix-n, guix-home-n, guix-profile-n at /var/guix/profiles/per-user/user/. PATH env is set automatically includes all three profile's latest bin/, so I can exec all packages under which profiles. So, guix command requires to set GUIX_PROFILE env. which I should choose to set?
<lurdan[m]>Another question, is about PAM. I installed swaylock with guix, and it seems that trying PAM authentication using /etc/pam.d configuration, which for debian's pam. swaylock uses guix pam library, so it fails (they differ in modules, config syntax, ...). I wish I can configure swaylock to use guix pam correctly, but How?
<jlicht>hello guix!
<mekeor-not-authe>hello guix :) does it make sense to install podman via guix on a foreign distro (debian testing)? i did so. now, when i run "podman network ls", why do i get this error?: command required for rootless mode with multiple IDs: exec: "newuidmap": executable file not found in $PATH.
<mekeor-not-authe>(background information is that i got a new computer for work, now running debian+guix instead of a proprietary operating system! yippie! :))
<nutcase[m]>lurdan: my swaylock works with the service definition here: I have swaylock installed in my home profile but not in system profile
<nutcase[m]>the service is included in my operating-system definition
<nutcase[m]>lurdan: this works with the latest commits to guix (I think in the last 5 days something changed:
<mekeor-not-authe>ACTION tries installing "shadow" package
<mekeor-not-authe>installing "shadow" solved that problem!
<mekeor-not-authe>ACTION stumbles into the next problem :D
<ytc>hello. .bash_profile file created by "guix home" overrides PATH variable with eval "$(guix package --search-paths)" so .guix-home's .profile doesn't effect anything.
<civodul>cbaines: yay! thanks for checking
<ytc>is this a bug or did i something wrong?
<civodul>cbaines: actually i think i had it build somewhere this week, but i switched context and lost track of what i did
<civodul>ytc: hi! you had set a custom PATH value in ~/.profile?
<civodul>so you mean it's setting PATH relative to ~/.guix-profile instead of ~/.guix-home/profile?
<ytc>yes, i expect it to append those paths
<ytc>it sets only for guix package
<civodul>ytc: could you send a bug report to
<civodul>please make sure to include the output of "guix describe" and your Home config (or a stripped version thereof)
<ytc>i figured it out.
<ytc>but there's still an issue on default .bash_profile file when guix is first installed.
<ytc>eval "$(guix package --search-paths -p $HOME/.config/guix/current -p $HOME/.guix-profile -p /run/current-system/profile)"
<ytc>this command overwrites PATH variable.
<ytc>. "$GUIX_PROFILE/etc/profile"
<ytc>this doesn't overwrite but append
<ytc>so changing it to the latter one does what i want
<civodul>where do you see that command? i don't see it in my home but it's not a first install
<ytc>i have freshly installed gnu guix 2 days ago. it's default .bash_profile includes it. maybe it wasn't there when you installed it.
<civodul>and you installed it with on top of another distro?
<ytc>actually, my older guix system's .bash_profile also doesn't include that command.
<ytc>civodul: no
<civodul>could you elaborate? :-)
<ytc>i installed the *latest* one so there may be a problem on that image
<civodul>you installed what? Guix System?
<ytc>guix system, yes.
<lurdan[m]>nutcase: OK, thank you! I'll try to configure that service into home services.
<civodul>ytc: i see that /etc/skel/.bash_profile ignores ~/.guix-home/profile
<civodul>i'm not sure it matters though because Guix Home provides its own ~/.bash_profile that replaces this one
<ytc>no, it prepends to the legacy ones
<civodul>prepending is fine though, right?
<civodul>anyway, i'm sure it's a case where we'd do a better job by email with a full description of the problem :-)
<ytc>well, it depends. in my case, it wasn't okay.
<ytc>i didn't see any other people complaining about it, therefore i thought i'm cursed or something.
<civodul>funny: overdrive1 uses a non-standard SSH port, yet it's being hammered (roughly one attempt per second)
<cbaines>civodul, I think the berlin overdrive configuration has password auth for SSH enabled
<cbaines>which probably encourages brute force attacks
<civodul>actually it has (password-authentication? #f)
<cbaines>I changed this a few weeks ago, and I'm guessing you might not have reconfigured since then
<bjc>i think there are lists that get shared. once one of my machines gets found, i start getting hit from all over
<bjc>i wish ssh didn't announce itself on connect
<rekado>berlin’s firewall now allows SSH on a different port; we should change that in our configuration too
<civodul>cbaines: ah that's good; i'm reconfiguring overdrive1 just now
<civodul>i wonder if we should set up say monthly unattended upgrades on build machines
<attila_lendvai>i have set up an nftables based rate limit on ssh. i'm not an expert in this, but i'm happy to share as a baseline if someone wants to experiment with it. with a cursory testing it seems to work
<bjc>i use fail2ban to deal with it
<attila_lendvai>civodul, random: i'd call catch-system-error as ignore-system-errors, or with-ignored-system-errors, or anything that suggests it'll be swallowed. (in my emacs i even have a more visible syntax coloring for such operations)
<civodul>attila_lendvai: oh hmm, makes sense
<attila_lendvai>i wasted too much time due to them, especially when not used wisely enough... sometimes they are needed/reasonable, but they should stick out.
<civodul>you mean in the shepherd?
<civodul>i found catch-system-error to be good, because it's very much like catch 'system-error
<civodul>but "ignore" may be even clearer
<nutcase[m]>lurdan: I added the service to my (operating-system (services ...)) list, not to my home-services
<attila_lendvai>civodul, no, in general: throughout my years of programming, silently swallowed exceptions are one of the major causes i had to spend time on debugging.
<attila_lendvai>civodul, catch-system-error is not a bad name. what i'm proposing here is to stick to a pattern, and add coloring to it. e.g. i have one for with.*ignore in my emacs.
<civodul>oh, got it
<civodul>catch-system-error is used in a few places in the Shepherd and in Guix, not a lot
<civodul>so we could already highlight it
<attila_lendvai>coming from CL, i grew to like the with-foo pattern for anything that has a dynamic extent
<civodul>new blog post!
<jlicht>very promising
<attila_lendvai>civodul, while we were discussing exceptions, i was bitten by the fact that no error gets printed, nor the operation interrupted, when a substistute is not authorized by a PGP key:
<attila_lendvai>an inconsistency: (define-public iproute ... (name "iproute2")...
<mirai>:)) I've stumbled on that one as well
<attila_lendvai>i think it's a general issue to be resolved that there are two distinct, ad-hoc, and inconsistent namespaces to keep track of packages (scheme modules, and the reified package registry).
<attila_lendvai>not a burning one, but it's not ideal as it is
<attila_lendvai>what is the best strategy if i want to use `ip route add` in the post-up of a wireguard-service? looks like it is not in the path, and i can't use a file-append, because it's not a GEXP (and a #<...> gets silently printed into the generated .conf)
<attila_lendvai>shall i just use /run/current-system/profile/sbin/ip ?
<attila_lendvai>a direct package reference would be nicer, but it works.
<attila_lendvai> is probably long obsolete
<mirai>what's happening right now?
<mirai>do started services never restart upon a reconfigure?
<rekado>not all do
<attila_lendvai>i was wrong, it's not obsolete. currently running services are not touched by a reconfigure.
<mirai>(I only briefly looked at the linked issue) I think this kind of ability would best belong in a user-specific script that wraps reconfigure
<attila_lendvai>i was just searching for an issue with shepherd-service-canonical-name before reporting mine, and i was too quick to judge.
<mirai>since a service being "restartable" doesn't necessarily mean that "I want it to restart"
<apteryx>mirai: never
<attila_lendvai>FTR, i've reported this: one (provision is allowed to be empty that breaks shepherd-service-canonical-name)
<apteryx>only new services are started
<apteryx>unless new features of Shepherd have made my knowledge obsolete
<civodul>would one really want "reconfigure" to restart xorg/sshd? :-)
<mirai>Such a feature looks like a recipe for disaster (from a glance, it looks ill-defined)
<mirai>actually, forget about the script wrapping reconfigure idea
<mirai>it looks like the job for it
<mirai>attila_lendvai: is a shepherd-service with (provision '()) valid to begin with?
<ngz>Hello folks!
<attila_lendvai>mirai, no, but it's allowed to happen.
<mirai>I'm inclined to think "no" since what would "herd status" list it as?
<mirai>by allowed you mean from guix right?
<mirai>or does shepherd really allow "anonymous" services to exist
<attila_lendvai>mirai, the issue is that it's allowed at instantiation time, and it leads to an error much later (in my case at the very end of reconfigure when services are started). the backtrace is not helpful, but luckily it contained shepherd-service-canonical-name that i grepped to get a clue about the underlying issue.
<attila_lendvai>mirai, the instantiation of the service object does not error with an empty provision, nor anything else until the end of reconfigure
<mirai>perhaps a (sanitizer (lambda (lst) (when null? (raise …)) lst)) on the record-type of the service would suffice to fix it?
<mirai>*(null? lst)
<civodul>or better: (match lst (() ...) ((_ ..1) lst))
<civodul>this way it checks that it's a "proper list"
<mirai>for even stricter check: (((? symbol) ..1) lst)
<mirai>*(? symbol?)
<mirai>unrelated, but there's a "new" match (not in guile yet™) introduced in SRFI-241
<civodul>oh, didn't know; what's interesting about it?
<mirai>for starters, (not surprising) the syntax differs from (ice-9 match)
<mirai>the pattern variables require unquoting
<mirai> <>
<cbaines>ngz, I prompted the data service to check for substitutes for tex-team, and the situation is looking pretty good
<cbaines>(for some reason it didn't know about a bunch of armhf-linux substitutes)
<ngz>cbaines: OK. So, I assume it's a good time to merge it, finally.
<ngz>cbaines: WDYT?
<cbaines>one moment, I'm just going to try and check how the changes on master overlap with the changes on tex-team...
<apteryx>uh? herd: error: /run/user/1000/shepherd/socket: No such file or directory
<apteryx>seems it disappeared
<apteryx>but my user shepherd is still running
<civodul>uh, not great
<apteryx>my system is dated at May 17 commit deda3cc9057f20b1e3d34d63a64da0bdd6ca1998
<mirai>apteryx: there's a bug on this iirc
<apteryx>user profile which has shepherd also dated from May 24
<apteryx>it's shepherd 0.10.0 out /gnu/store/nl0948z46yndpx3kihhi540l5c422wv4-shepherd-0.10.0
<civodul>mirai: a bug on what?
<mirai>civodul: missing socket but running
<civodul>mirai: it's not a bug report per se, AIUI
<civodul>more of a discussion
<civodul>(which i think is better suited for guix-devel)
<apteryx>if I skip most of the discussion, it seems the bug would be 'never delete the socket file, no matter what happens in the services'
<cbaines>ngz, unfortunately I think there's significant overlap (3579 x86_64-linux packages) between the big changes pushed to master, and those on tex-team
<civodul>apteryx: shepherd never deletes its socket, fortunately
<apteryx>are you confident that what Maxime imagines in can never occur?
<civodul>ah well, actually call-with-server-socket does delete it upon exit
<ngz>cbaines: what do you mean by "overlap"?
<cbaines>ngz, like tex-team affects sbcl, but that's also been changed on master
<cbaines>ngz, so if you were to merge tex-team now, that would generate a new unseen derivation for sbcl (because of the combination of the master and tex-team changes), so it and all of it's 1615 dependents won't have substitutes)
<ngz>cbaines: OK. So, do I need to rebase tex-team on top of a green flagged commit and let the CI build again?
<apteryx>civodul: :-) so that's likely the problem/bug, right?
<civodul>apteryx: looking at fork+exec-command, i'm skeptical this can happen; we'd need a reproducer
<cbaines>ngz, I've sort of given up at this point. There's little value of trying to follow a process for branches if that process isn't being followed, and other changes are just pushed to master.
<civodul>apteryx: could you check what you have in ~/.local/state/shepherd/shepherd.log?
<ngz>cbaines: You shouldn't give up :) I think branch are a promising way to process patches, but the community needs time to use it properly.
<cbaines>ngz, you've already rebased several times, so we're just going around in circles. We may as well just stop and join the crowd pushing oversized changes directly to master.
<apteryx>civodul: i'm afraid it's unhelpful:
<civodul>cbaines: don't give up! we need to have a discussion all together i guess!
<attila_lendvai>i still think my analysis in is valid (although i haven't looked very closely on the more recent changes in shepherd). it's not a bug per se, because start GEXP's should not throw errors, but life happen.
<ngz>cbaines: To tell the truth, I have no problem rebasing an n-th time.
<attila_lendvai>ACTION needs to get afk
<civodul>cbaines: as i see it, we're still transition from the wild west to a more controlled process
<civodul>we have to change our habits
<civodul>apteryx: yeah, no idea what happened; i doubt shepherd deleted the socket, but it could be that it hasn't created it yet if it's still evaluating the config file
<civodul>depends on what's in there
<cbaines>ngz, well, it's up to you, I don't particularly mind either way
<apteryx>civodul: it's been 9 days, eh. I haven't touched that config in years.
<apteryx>but it could be that Emacs had some problem
<ngz>cbaines: I'm stubborn! I'll rebase the "tex-team" branch on top of a green commit in a while and let you know.
<civodul>apteryx: or all of /run/user/1000 got cleared for some reason?
<apteryx>I noticed about it when Emacs became buggy (buffer went black, then something stuck in the minibuffer prevented any other action -- so I wanted to 'herd restart emacs')
<apteryx>/run/user/1000 seems properly populated
<apteryx>cbaines: I agree a discussion is needed, haven't been able to catch up with these yet, apologies.
<apteryx>but mostly what's needed is the new policies to be drafted in Contributing.texi
<civodul>i think little is missing from
<civodul>the branching strategy needs to be added:
<civodul>but that's about it
<apteryx>we're in an uncomfortable in-between, where we haven consensus (I think?) to explore a new direction (feature/teams-based branching flow) but the operational details are still fuzzy
<civodul>not so much actually
<civodul>the commit policy is quite clear, and the branching strategy will clarify the remaining bits
<apteryx>the commit policy still talks about staging and core-updates
<civodul>yes, the branching strategy fixes that
<apteryx>what branching strategy? :-) is there a draft somewhere?
<apteryx>ACTION checks #63459
<civodul>there was too little feedback
<cbaines>apteryx, the current branching strategy is here and there are some patches at
<cbaines>apteryx, the current commit policy doens't mention staging/core-updates or branches, it just says about posting changes to
<cbaines>I'm hoping that the restructuring in #63459 will make things a bit easier to grasp, as I think it better groups the "what to do with changes" stuff and just references it from the commit policy
<apteryx>OK. I'll get up to speed with this patch when I get a chance to read it carefully, thanks
<apteryx>ACTION must vanish back into the $work abyss
<apteryx>weird, the shepherd bug doesn't go away with a session restart. even starting shepherd by hand leaves me a nonexistent /run/user/1000/shepherd/socket
<apteryx>the tail of strace ... shepherd reads:
<apteryx>shepherd itself backgrounds successfully, returns status 0
<lw>Hey, question, is there a package I can install to manage `make`/`cmake` environmental variables? It seems they can't find the packages I have installed etc
<lw>Like the `gcc` compiler
<jlicht>lw: for gcc, you'll probably want to use `gcc-toolchain': "guix shell make gcc-toolchain" should give you a basic shell with gcc and make set up
<lw>It did work
<lw>Now, I get another error: `st.c:2: error: cannot find 'ctype.h'`
<jlicht>lw: that should really Just Work; how do you include ctype.h?
<jlicht>lw: are you using "#include <ctype.h>"? I'm not a C guy, but that works for me in the guix shell command I gave you
<ngz>cbaines: "tex-team" has just been rebased on a recent master commit.
<lw>jlicht: I'm just downloading my st build and trying to build it. Here is the github repo
<lw>I'm not a C guy either lol
<lw>yes, I'm using `#include <ctype.h>`
<lw>Where can I find the possible `guix shell make` options?
<jlicht>guix shell allows you to use software without "installing" it first, in the traditional sense. It doesn't really add any new options to the software itself
<jlicht>lw: If you have a local checkout of that repo, try "guix shell -D st harfbuzz -- make"
<lispmacs[work]>question for the emacs users: if I install an emacs package via guix, is there a way to make it visible without restarting emacs?
<jlicht>lw: the "-D st" makes it include (almost) everything needed to build guix's st package, and I believe your fork in particular also needs harfbuzz (untested assumption)
<lw>I still get this `cannot find 'ctype'` error
<VesselWave>lw: Are you still here? I've built your fork with guix package definition
<lw>Yes, I'm here!
<lw>VesselWave: how come? (happy face)
<VesselWave>So I can explain you how to create guix channel so you can do it too
<VesselWave>Create a dir and put this file in it
<VesselWave>guix build -L ~/path/to/dir st
<VesselWave>and change (my st) to (st) at top of the file
<lw>Alright, will do it
<lw>Just trying to copy inside emacs irc without evil binds is being hard (sad face)
<lw>alright, did it
<pistrie>hi there. Im interested in trying out Guix, but I ran into three issues. 1) is there a reason that GNOME is an older version? 2) how do I use wayland with GNOME? 3) how do i declare my packages? Is the `guix install` command going to add it to some list? I think I would prefer to declare my packages in a file like how you declare your packages in
<VesselWave>lw: If build is successful you can `guix install -L ~/path/to/dir st`
<VesselWave>lw: I also submitted contact form on your site yesterday have you received it?
<lw>VesselWave: You can email me via
<VesselWave>lw: Thanks
<lw>I guess that form is no longer functional on the website. I must remove or repair :D
<lw>Thanks a lot for the contact. Eager to talk to you
<VesselWave>lw: Is build succesful?
<jackhill>pistrie: for 1) we just haven't completed the work to update GNOME yet. Hopefully soon!
<jackhill>2) GDM will only offer to start GNOME's Wayland session if it is also running under wayland. Make sure you have the wayland? option of the gdm service set to #true.
<lw>VesselWave: here, i get `guix/platforms not a directory`
<jackhill>3) you mean not to define your own packages, but rather to select from the available package collection, right? For that see the --manifest option to `guix package`
<jackhill>pistrie: oops, it looks like I'm being called away from the computer. Hopefully someone else can step in if you desire longer answers.
<VesselWave>lw: I use command like this `guix build -L ~/repos/chanelio st`. Have you put the path relatively to home dir?
<lw>VesselWave: it worked!!
<lw>I didnt type st in the end
<lw>my mistake. sorry
<VesselWave>lw: next install or try in shell. Just change `build` to `install` or `shell`
<lw>VesselWave: So, `guix build: warning: failed to load '(st)': no code for module (st)`
<lw>./st/st.scm:1:0: warning: module name (my st) does not match file name 'st.scm'
<pistrie>jackhill yes i mean from the standard packages. so in nixos theres a configuration file where you declare which packages you want on your system. If I declare the neovim package and rebuild the system i will have neovim available to me
<lw>VesselWave: guix build -L ~/dotfiles/guix/st st
<lw>I used this command
<lw>my `st` did change
<lw>Not quite my build I guess, but seems like it partially worked
<johnabs[m]>Hi guys, I'm having some issues with LaTeX, namely the package ninecolors seems to be missing. I've never gotten this error before, and it seems that it should be included in texlive, but it's not present when I run kpsewhich. Has anyone else had this issue?
<VesselWave>lw: You should have a path relative to what you specify in -L. So if your file is ~/dir/dir2/dir3/st.scm and -L is `~/dir/dir2`, you should have (define-module (dir3 st)
<VesselWave>lw: Hope it's not too complex :)
<lw> I see
<lw>I will make the modifications
<lw>Not at all, makes sense
<lw>All right, worked without any further errors
<VesselWave>lw: install or shell ^
<lw>VesselWave: I will brb, supermaket etc. When I'm back I will let you know, alright? Thanks for the help. Looking foward to learn more about the guix channel setup
<lw>I used build
<VesselWave>lw: Ok
<lw>I was able to start st with new configs. But, it seems to be lacking the proper config, like Shift+M+up should resize to a bigger font. But, we figure it out later, no problem
<lw>Thank you very much
<VesselWave>lw: Have you got an email?
<nutcase[m]>Hi, is anyone here happy with his/her flatpak installation on a guix system and able to share it? I have problems with xdg-desktop-portal / dbus, I think. Links in a flatpak app don't open in my browser.
<ieure>That's just how Flatpak is: shitty.
<carmenshea[m]>nutcase[m]: Hello. Flatpak runs fine on my guix install. I have both xdg-desktop-portal and xdg-dbus-proxy. You'll also need to have dbus launching on the start of your windows manager (I'm running sway). My flatpak apps are Firefox, Session Messenger, Thunderbird, and Skype. All run fine.
<mekeor>i once tried one application via flatpack. after finding out the requirement of dbus, it worked fine~ish :)
<mekeor>since then, i have this as last line in my ~/.xinitrc: dbus-run-session -- ~/.xmonad/xmonad-x86_64-linux
<carmenshea[m]><nutcase[m]> "Hi, is anyone here happy with..." <- This is the line I use to launch D-Bus when Sway loads. This is in my .bash_profile [ "$(tty)" = "/dev/tty1" ] && exec dbus-launch --sh-syntax --exit-with-session sway
<nutcase[m]>carmenshea[m]: I launch it with `[ "$(tty)" = "/dev/tty1" ] && exec dbus-run-session -- sway` Do you know the exact difference?
<nutcase[m]>and did you install flatpak, xdg-desktop-portal and xdg-dbus-proxy in your home profile or via guix install ...?
<carmenshea[m]><nutcase[m]> "Hi, is anyone here happy with..." <- It looks like your line doesn't actually launch dbus. Try copying my line. As to Flatpak I installed flatpak from the Guix repository:
<mekeor>nutcase[m]: comparing "man dbus-launch" and "man dbus-run-session", the first sentence of the DESCRIPTION section differs by dbus-run-sessions also "start[ing] a specified program in that [launched] [dbus-]session."
<carmenshea[m]>mekeor: Yep, I came across the line in the Sway wiki.
<mekeor>i think dbus-run-session fits slightly better here :D
<mekeor>but it does not matter much :)
<mekeor>if at all :D
<carmenshea[m]>mekeor: In this case I'm absolutly NOT an expert. I just copied that line...voila it worked.
<nutcase[m]>carmenshea: my ps says there is a dbus-daemon --system and also a dbus-daemon --session running. I assume, that it won't change much, but I can try. How did you install flatpak from guix repository? Did you install it via `guix system`, via `guix home`or via `guix install`?
<pistrie>Can anyone tell me the correct way to installing packages? On NixOS you can use a config file where you declare which packages you want installed on your system. Then you do a system rebuild and the packages will be installed on your system. Does Guix have a similar system? I've heard that the two are pretty similar in design philosophy
<carmenshea[m]>nutcase[m]: Follow the link that I sent for the flatpak install via guix. From there you'll need to go to Flathub, find the app you would like to get and install using their install command suggestion...then launch using their launch suggestion.
<nutcase[m]>carmenshea: My problem is not installing flatpak apps. I have flatpak apps installed on my guix system. My problem is that a click on a link to some web page in a flatpak app container doesn't open a window of my (non-flatpak) browser
<mekeor>pistrie: yes, you can specify a list of packages that should be available system wide. it's the "packages" field of the "operating-system" record.
<carmenshea[m]>I've got a client coming in...I'll touch base a little later. I will help where I can. Cheers
<mekeor>pistrie: if you want to specify a list of packages that should be available in your user profile, you can either use a manifest.scm or use "guix home".
<mekeor>pistrie: last but not least, you can of course just install packages into any guix profile, e.g. your user profile, with "guix install hello"
<pistrie>thanks! would you be able to link me to some documentation so i can read up on it myself? Isnt `guix home` or `guix install` imperative instead of declarative? Basically what I'm trying to accomplish is that I have an overview of the packages installed on my system
<mekeor>pistrie: guix-home is declarative, just like manifest.scm
<mekeor>pistrie: "guix install" would be a little-more imperative-ish approach. but you can always type "guix package --export-manifest" to get a manifest.scm, and thus, an overview, (including package transformations, btw)
<mekeor>pistrie: guix has good documentation. it's worth getting comfy with an info-reader. e.g. emacs, or just "info guix" :)
<mekeor>(then, you can easily search the manual etc)
<mekeor>but the web docs are fine, too :)
<pistrie>thank you
<mekeor>here's the full manual on one large html page:
<mekeor>for Ctrl+f ;) -- but there is also an "index" at the end of the manual :)
<mekeor>pistrie: oh and the system wide packages list is documented here: (maybe search for "packages")
<Guest28>If i need an older version of a package, what would be most efficient way to search the package definition in an older guix version so I can just copy paste it for my case?
<mekeor>Guest28: there is guix time-machine which allows you to install packages which had been declared in previous guix versions
<mirai>What do I need to do in order to get these new files picked up by make for guix? Output from git status <>
<mekeor>mirai: did you introduce a new directory for a single file?
<mekeor>mirai: wildly guessing, add here:
<mekeor>ugh, why did git-link.el use the github-mirror? sorry!
<mekeor>better link :D
<mirai>mekeor: thanks
<csepp>uhm, i'm trying to run guile from a local checkout, freshly built, i get this: undefined symbol: __libc_pthread_init
<csepp>pre-inst-env doesn't fix it
<mekeor>csepp: can you please share all relevant shell commands you executed?
<mekeor>does anybody know how to make emacs/geiser/guile REPL show the documentation for a "syntax" like emacs-substitute-sexps?
<csepp>uuh, i rebased onto a recent commit (one from about an hour ago), ran git clean -Xf, i think make clean too, then ./boostap, ./configure, make -j 4
<Guest28>I want to build the Linux version from Raspberry and it says that it can't find openssl/bio.h although my openssl package has in it.  Does someone know why this happens? It's that line of code
<mekeor>csepp: did you run this inside "guix shell -D guix help2man git strace"?
<csepp>guix shell -D guix, yes
<csepp>the same way i've been building it for like 2 years
<csepp>gonna try switching to the origin/master branch and build that :/
<csepp>oh also i recently cleared ~/.cache/guile
<ngz>Hmmm I get "no code for module (guix ui)" when I try to send a patch with git send-email.
<mekeor>ngz: oh weird. what does guile have to do with git-send-email? :D
<ngz>mekeor: "make" adds this "headerCmd = etc/teams.scm cc-members-header-cmd" to the [sendemail] section of git config.
<mirai>apteryx: regarding jami-account->alist, can the string-null? check be replaced with something along the lines of (if (maybe-value-set? x) serialized-value #f)
<csepp>mekeor: origin/master also broken
<lilyp>mirai should list-of-ini-entry have a ? at the end?
<mirai>nicely spotted
<lilyp>for the test, you might want to use something that doesn't expose your taste in music, perhaps a story about counting sheep?
<mirai>ahaha, the test really was me not feeling creative enough to devise some "intelligible" data
<mirai>so I just grabbed whatever was available on the desktop at the time
<mirai>but sure
<lilyp>you could do the hot new thing of asking chatgpt to write some for you
<lilyp>not that I'd endorse doing so
<lilyp>for the serializer kwargs, I can somewhat see the necessity when going to the ini serializer, but I think (serializer-options) might be more neutral in language and possibly broaden the applicability
<mirai>I'll pass on the chatgpt offer :) since it's a SaSS that demands signup
<lilyp>regarding the earlier issue of serializing multiple fields together you might also want to think about whether it's possible to stitch something together using G-Expressions