IRC channel logs


back to list of logs

<elais[m]><pkill9> "anyone know of a wayland..." <- DWL Guile. Good luck.
<shcv[m]>Does guix clobber /boot/efi, or can I share that partition with multiple efi OSes?
<shcv[m]>Or do I need to make a separate boot partition for guix to dual boot?
<nckx>Clobber /boot/efi?
<pkill9>i like your avatar shcv[m]
<nckx>I like your… randomly-assigned nick colour.
<shcv[m]>I'm just wondering if there can be multiple boot directories in /boot, since I think guix makes one named "Guix"
<superkamiguru>Does anyone know the best place to start if I was interested in trying to extend the (file-system ...) declaration to work with 9p? I imagine the best place to start hacking would be in gnu/system/file-systems.scm.
<nckx>shcv[m]: That's how (U)EFI is supposed to work.
<nckx>Guix will create a ‘boot entry’ in NVRAM (also ‘Guix’ I believe), and \EFI\Guix.
<nckx>Unless you use the ‘removable’ grub-bootloader variant.
<shcv[m]>Ok, so I can share the same boot partition with multiple OSes
<nckx>Of course.
<nckx>We're not sociopaths.
<nckx>Unlike… some other OSes.
<nckx>shcv[m]: Now, some (arguably buggy) firmware won't let you choose which boot entry to boot, or will randomly forget your choice. In that case you'll have to install an overarching boot loader, but that's unusual.
<nckx>‘grub-efi-removable-bootloader’ could be used for that. It *is* kind of clobbery, though, so beware of that.
<cbaines>nckx, out of interest, what's going on under your user on bayfront?
<nckx>I'm trying to build a meaningful graph of… stuff.
<nckx>It's majorly inefficient though.
<superkamiguru>seems like the best solution is to avoid the (file-system ...) declaration all together for 9p, and just use some service to run the ' mount -t 9p -o ....' command
<superkamiguru>Just updating my findings
<cbaines>nckx, ah, ok :)
<nckx>cbaines: Aside but related: bayfront has an impressive uptime of 443 days. After serving it cake, maybe it should be updated & rebooted? Or is that risky?
<nckx>Us berlin folk are rather traumatised in that area :)
<cbaines>perhaps, but I think the only remote access is to power cycle the machine
<cbaines>so it's a little risky, but probably less problomatic than berlin
<nckx>cbaines: Never mind. I was thinking we upgrade to the last commit before the shepherd bump that is suspected to be buggy on berlin. That's probably not (as) worth it, even if a 1y+ kernel makes me uneasy. Let's wait.
<superkamiguru>Just realized this isn't the right chat for what I have been posting. So I am totally sorry for the spam!
<nckx>Mainly because we can't be 100% sure that's what's causing it, although it's exceedingly likely.
<nckx>superkamiguru: I'm sorry that I haven't been able to help you, but it didn't seem wildly off-topic? I don't know where else you would have asked. You certainly didn't spam.
<nckx>I don't use any network file systems myself.
<superkamiguru>Oh ok, I was worried I had been incorrectly posting.
<superkamiguru>Well hopefully what I have found can help someone else, and I am going to see if maybe I can start working on adding support for 9p. Probably a bit out of my wheelhouse but it seems interesting
<nckx>Having read your messages: you are in the right place.
<nckx>There is also the help-guix@ mailing list, which isn't more correct, it's just different. IRC is great for real-time help, but more luck of the draw (or time zone).
<superkamiguru>Ok well, then I will post any additional findings here and might reach out to the mailing list as well. Seems like there is already the beginnings started for 9p support which is great
<nckx>Sounds great! Don't hesitate to ask for help if you get stuck.
<superkamiguru>For now though it seems like just creating a one shot service that runs the mount command is the best way to go, for anyone else looking
<nckx>People don't tend to respond when they don't know the answer, but it doesn't mean they're annoyed.
<superkamiguru>I just get worried that I am missing something and am just embarrassing myself haha
<nckx>It's not implausible that this is still TODO.
<superkamiguru>Yeah, there is some stuff in gnu/system/vm.scm for detecting mount-tags, and it seems like it should be possible to use it for file-systems, but it seems vm.scm is doing a bunch of extra fancy magic to allow mount_tags instead of a normal "/dev/xxx/" value
<nckx>cbaines: Do you just keep regular eyes on the bayfront graphs, or do you have some kind of active alert set up? And if so, is it available as a Guix service?
<superkamiguru>So I guess tl;dr is that the built in vm functionality uses mount-tags as the string value for (devices ...) under file-systems, but the standard file-systems library isn't configured to.
<nckx>That's my understanding: what little 9pfs support there currently is, is specifically for the QEMU VM code. It can't be repurposed as-is for non-VM Guix Systems (or even general-purpose 9pfs support on either kind of system).
<nckx>Although of course it's a starting point. Just don't feel like you're doing something wrong if you're rewriting/designing parts.
<superkamiguru>Seems like there could be some changes made to file-systems.scm to allow for it the same way that vm.scm is.
<nckx>I haven't used NFS either, but I assume the file-system code needed to be extended for that as well.
<superkamiguru>Not really sure what the correct answer is, but since vm.scm is modifying the mappings for file-systems to allow for mount-tags, is it possible that mount-tag mapping functionality should just be moved to file-systems.scm for general use? I am probably talking out my butt a bit here
<superkamiguru>Not sure if that technically is overwriting the default file-system functionality
<superkamiguru>or if the mapping changes allow for one to use either/or
<nckx>I'd have to read vm.scm with a lot more attention than I can currently spare, sorry :)
<superkamiguru>No problem, thanks for the help!
<nckx>sneek: later tell antipode: I tried building dejagnu on berlin a few times and it failed, even with -{M,c}1. When I ran it in a loop with those options it eventually succeeded.
<sneek>Will do.
<nckx>Good night.
<nckx>sneek: botsnack
<the_tubular>is it possible to control a whole network with a scheme file ?
<pkill9>do you ever feel like you're wasting energy adn such with remote builds?
<the_tubular>Well I guess, multiple scheme files
<pkill9>control a whole network how?
<the_tubular>Yeah sorry, don't really know how to ask that question.
<the_tubular>Let's say I have a router, a switch, a firewall, and a server hosting a webserver
<the_tubular>Could I run guix on all those machines to control my routing, my firewalling, or even VLANs in my switch ?
<the_tubular>And also the firewall on the webserver
<the_tubular>Kind of like Software Denifed Network, through guix
<the_tubular>Does that makes sense ?
<pkill9>yes you can
<pkill9>see `guix deploy`
<pkill9>or just run scripts usign ssh
<the_tubular>I know I can deploy on the machine, I just don't know how to configure network in a '"guixy' way
<the_tubular>How do I configure nftables with guix ?
<apteryx>I think currently you're stuck with one shot shepherd services that manually invoke the command
<apteryx>oh, I spoke too soon; we have a nftables-service-type service
<apteryx>the_tubular: ^
<the_tubular>Ohh, can you link it ?
<apteryx>info guix RET i nftables RET
<apteryx>or info '(guix) Networking Services'
<mroh>the_tubular: or
<the_tubular>But nftables was also part of the puzzle
<daviid>rekado_: did we not agree that guix would not change my package(s) name(s), i see g-golf has been renamed ...
<daviid>rekado_: not saying you are responsible for the (second time) renaming, i am asking (you if we agreed ...) because iirc, that discussion about not renaming g-golf happend here and with you, and at the time you were a guix maintainer ...
<daviid>but anyway, who's in charge, please keep g-golf as the package name, not guile-g-golf, thanks
<nckx>daviid: Why?
<daviid>i don't want to discuss this actually, just keep my package name
<daviid>and it as been discussed already about trwo years ago, we agreed here not to rename without perms ... thanks
<Cairn>daviid: Seems like it was renamed in order to specify multiple packages with multiple guile versions. There's `guile2.2-g-golf` and `guile-g-golf` which uses Guile 3.0. Isn't that an important distinction?
<Cairn>I can't find the earlier discussion in the irc logs, but I'm curious.
<nckx>That's because it's not there.
<nckx>There is no public discussion with rekado about g-golf.
<daviid>or in #guile, but i definitely asked and as you can see, it was named g-golf (after my claim)
<Cairn>I don't see it renamed in the commit history. Was the rename only discussed previous (but not applied)?
<daviid>in the guile-xyz.scm package file, the g-golf is 'deprecated
<Cairn>Yeah. That's the only time it's had a change like that
<Cairn>What would you like the guile2.2 version to be called instead?
<nckx>There's no such promise in #guile either. Only one-sided ‘I don't like it’.
<daviid>g-wrap hasn't been renamed by the way, which is good
<daviid>Cairn: i'd rather add a postfix then a prefix
<nckx>(Which is not me paraphrasing you by the way, it's the second quote.)
<Cairn>But you'd want the guile3.0 package to just be `g-golf`?
<Noisytoot>Adding a postfix would make it inconsistent with other packages
<daviid>just g-golf, than let's think about the other name a minute :0
<Cairn>You wouldn't mind just repeating your reasoning briefly, would you?
<Cairn>I'm just curious
<nckx>Heh, this was the one case where the stuck-in-the-past search form on logs.guix would have been handy, and I futzed around with SSH and grep. Sigh.
<nckx>s/been handy/just about worked/, let's not get carried away.
<yuu[m]>i also found it odd guix prefix names with the programming language it's constructed on. on nix they do it like `programmaing-language.pkgs.package-name`
<yuu[m]>so they just have it on a attribute set, not in the package-name
<daviid>nckx: it would be nice to have a search button on the guix package lst page, and also have the page selection number repeated on top, because as itis, searching for a package is a (sometimes long) trial and error procedure ... my 2c
<yuu[m]>guile having proper namespaces/modules, i can't understand the need for prefixing the name itself
<Cairn>yuu: Could do that wild thing that's showed up in Emacs mailing list where you use a slash instead of a hyphen. So `language/package-name` instead of `language-package-name`
<Cairn>Not being that serious though. It makes sense, what you're saying.
<nckx>daviid: Not a direct answer, but there is a second Web3 AJAX package page at <>.
<daviid>yuu[m]: i agree it would be nice not to have a prefix
<daviid>nckx: oh nice! man so much better :)
<daviid>so i seee 3 g-golf pacjages there
<nckx>I don't really remember why it's not on the main page.
<nckx>The Web site needs to be static, but IIUC the hpc version is all JS, so…
*nckx shrugs.
<Cairn>nckx: Wow, I didn't know about that search
<Cairn>Very cool
<Cairn>I'm not versed enough in Guile to know namespaced packages would look...
<nckx>daviid: Right, it doesn't filter out deprecated packages (apparently).
<daviid>very efficient, you should redirect the 'guix package page' to this url, imo
<daviid>yuu[m]: i'd rather use a postfix, ans a / to distinct from the package version number, which g-golf currently doesn't hvae because no official release yet
<daviid>sp g-golf/guile-3.3, g-golf/guile-2.2 ... would be acceptable (to me)
<nckx>I (both) think this has been discussed to death and (also) have no idea why this was the result.
<daviid>then when released, g-golf-0.9.1/guile-3.3 ...
<nckx>Re: the package pages.
<daviid>or keeping pkg-name[-x.y.z] (no slash guile-x.y) for the latest guile in guix would be better, and acceptable convention as well, i think
<nckx>daviid: OK, you're certainly welcome to start a thread on the mailing list to argue for changing the current naming conventions…
<daviid>so g-golf is fine, as the latest g-golf available (pre-compiled) version for guix, using the latet guix guile version
<daviid>nckx: oh no, thanks - but pleasekeep g-golf, then /guile-x.y for earlier version, thanks!
<nckx>I asked why, but you didn't answer.
<Cairn>daviid: What about using an alias package definition which provides the name `g-golf` as a reference to `guile-g-golf`. Would that be ok?
<nckx>(Not saying that's a good idea or not, but we could apply that to all ‘oh this is mainly used as a command, not a library, trust me’ style names where the language prefix is omitted.)
<nckx>(Which is interesting at least.)
<nckx>Although g-golf is squarely a library, so it's currently correctly named.
<Cairn>Yeah, daviid I'm not sure if you knew where this was going already, but I feel like you'll need a justification to go against the convention 😅
<nckx>I'm not saying I like it because I don't think I do. We'd have a huuge number of duplicate names for the same exact package. It would be better (again, not saying good 😛) to have a clear ‘aliasing’ system then, so packages still have a canonical name. That would also allow the CLI names to change, which is currently not possible. (define foo python-foo) will still show only as python-foo on the CLI.
<daviid>it is perfectly named :)
<nckx>I agree.
<nckx>daviid: Any more ideas where this conversation with rekado_ could have taken place?
<daviid>anyway, if possible, i would be happy to searchon this page youpasted here, and enter 'g-golf' and see g-golf or g-golf-x.y.z when official releases, then g-golf[-x.y.z]/guile-2.2 ...
<daviid>nckx: no, i'll stand corrected that there were no promise
<nckx><anyway, if possible> Right.
<daviid>but i'd apreciate we'd implement what we just talked about here
<nckx>I see.
<Cairn>nckx: So I shouldn't send patches if I see duplicate definitions? I put one of those on my todo list, but I'll take it off if it'll just be noise until a better system is set up to deal with them.
<nckx>Well, my advice stands: draft a good case for why why <library>/<language>-<version> is better than <language><version>-<library> and worth the switching costs, and we can discuss it.
<daviid>nckx: on this search url you pasted, i think it would be nice to make the 1st 3 columns larger, maybe
<nckx>The hpc one?
<daviid>it can't write the name and version without \n
<nckx>I don't have anything to do with that site but yeah, the version column is definitely redonkowide.
<daviid>i think i'd rather have | Name ... | Version ... | Synopsis/Home page, with the synopsis on a line, the home page on another line but in that clumn
<nckx>I was going to suggest dropping the home page (to the main package overview page) for that same reason.
<nckx>It's impossible to display that in a separate column without crowding out the rest.
<nckx>URLs being URLs.
<daviid>let me paste an org example ofwhat imean
<nckx>Not needed.
<nckx>I get you.
<daviid>ah ok
<Cairn>Did my message go through?
<nckx>Cairn: No, I think you should. For one, they are very likely to be mistakes (duplicate packages get added more often than you might think or like).
<nckx>Cairn: Which one?
<Cairn>Ah, sorry, I was impatient, haha
<Cairn>Alright, I'll try to keep an eye out then. Thank you! =)
<nckx>Thank you!
<Cairn>Packaging is hard. Seems like everything I want to package needs a fix upstream before I can submit a patch. 😢
<daviid>nckx: here, for others to look at as well, and including our 'today's discussion' aboutthe subject ...
<nckx>Humph, now I find a second instance of what is clearly the same script with sliightly different CSS, looks a lot better: (still agree it can be improved by merging).
<Cairn>Wow, that spacing is loads better.
<nckx>Yeh. No solution for narrow screens/windows, but better.
<nckx>It just hscrolls. Which actually… Maybe that is a good solution?
<nckx>Because it's only the table. So there's a natural cut-off of less-important info (the home page IMNSHO), whilst still keeping it perfectly visible for those who want it.
*nckx shrugs, again.
<Cairn>daviid: Not sure you're gonna get the package name updated, but I'll watch the mailing list thread if you make one.
<nckx>This is why I don't do Web stuff.
*Cairn shudders
<Cairn>web stuff
*nckx nods, shuddery.
*nckx also shrugging.
<nckx>Somebody gets worried and calls an ambulance.
<nckx>daviid: Package names can't include ‘/’.
<nckx>They are used as part of the /gnu/store/<hash>-<monolithic-package-name>-<version> store file name.
<nckx>‘Monolithic’ is my way of saying ‘this will not become a subdirectory, ever’.
<Cairn>nckx: Wait but
*nckx waits, shudders, nods, shrugs, and shimmies.
<nckx>Cairn: If you're about to raise ‘foo/fixed’-style grafts, let me save you the trouble: there's an (unfortunate, probably) difference between variable and package names.
<Cairn>Ok, never mind. I saw a package definition called `guile-ncurses/gpm`, but the actually package name is `guile-ncurses-with-gpm`.
<nckx>But if you're not, do carry on.
<Cairn>Yeah, I only brought that up earlier since I saw it on some emacs mailing lists as an idea of how to "namespace" packages
<Cairn>Like yuu mentioned earlier, I'd be curious for how that looks. But I, for one, kinda like the simplicity of using prefixes.
<nckx>So, purely technically, we could add such namespaces and simply strip them from the store file name, or turn them into a - (which we already do for versions, but there are actually places where we have no choice but to try to parse foo-bar-3.0-blurp back into foo-bar@3.0-blurp, and that's already scary, we'd best not add more things).
<nckx>But really
<Cairn>But yeah, I'm still curious why we wouldn't just use prefixes
<nckx>We do.
<Cairn>I mean the the g-golf case
<nckx>A prefix different from guile-?
<nckx>Or do you mean the current status quo?
<Cairn>Hehe, I'm not really sure; not meaning to cause confusion. I just don't think daviid's name change will be used. And I guess, in theory, some revolutionary change to packaging in order to remove language prefixes in favor of namespacing would fix their issue with the name, but I agree with you that namespacing doesn't really seem necessary
<daviid>nckx: that's quite unfortunate, no '/' in package names, it is (so much) better the way i propose in the 'screenshot' - can't guix have a presentation name and use _ in the store?
<Cairn>Sorry daviid, don't mean to talk about you like you're not here
<nckx>daviid: Well, again, why?
<nckx>Just like Guix won't rename guile-g-golf to g-golf just because you ‘don't like it’, we're not going to go through a costly name migration without first considering the benefits.
<daviid>to keep the presentation nice, and hide the implementation details ... rather then force a 'sub-optimal' presentation to keep the (hidden anyway) implementayion details?
<daviid>you should (guix) rename guile-g-golf as g-golf...
<daviid>you (guix) should not change a package name unless to add a postif as we discussed ...
<nckx>You're under no obligation to convince me but hence I will remain unconvinced. That seems fair?
<daviid>youare inverting the question 'priorities', the question is why would you rename a package name
<daviid>the package name isimportant
<Cairn>The package was renamed to match convention and to be able to express that it's compatible with multiple guile versions. Seems like a good reason to rename.
<daviid>it is quite offensive to see it renamed, but acceptable to see additional postfix notations for guile's version
<nckx>Ah. Because we prefix all library packages (such as g-golf) with their programming language name, hence python-foo and r-bar and haskell-boopleblorp. C/C++ is a (perhaps unfortunate) exception, but that's just because Unix == C and historical raisions.
<daviid>Cairn: g-wrap hasn't been renamed, as an example
<nckx>That's an oversight.
<nckx>I won't rush to rename it because that would be needlessly provocative, but it's still the case.
<Cairn>g-wrap should be renamed to match convention.
<daviid>renamingis offensive
<Cairn>Why is it?
<nckx>It's not more offensive to prefix than to suffix, surely.
<daviid>quite the contrary
<Cairn>My goodness
<nckx>So you're going for a GNU/Linux type distinction, where / means ‘runs on’?
<nckx>That's a valid convention, but it's not a superior one I think.
<nckx>Well, I can only repeat my invitation to discuss this on guix-devel@ (‘the mailing list’ above). Even if you did manage to convince one person here, that wouldn't be enough, I think. Also, the g-golf → guile-g-golf commit you object to was pushed by the person who was co-maintainer alongside Ricardo, so I doubt you ever managed to convince them as you claim.
<Cairn>anon17: 👋
<anon17>live, manual install, wifi interface not found, when I type ip address.. please suggest..
<daviid>why not C-postgresql then
<anon17>ifconfig -a and its not showing wifi interface, am i missing anything?
<Cairn>daviid: I don't know much about postgres, but is it a C library?
<daviid>Cairn: mostly, but the point being you'find numerous counter example tothes convention
<daviid>as i said, why g-wrap?
<Cairn>daviid: I guess you'll have to argue that on the mailing list then
<Cairn>anon17: Did you check if your hardware is compatible with the Guix iso? There's a limited set of wifi cards supported
<daviid>i won't
<Cairn>daviid: Sorry then
<daviid>well i am sorry, my package name was changed without my authorization
<Cairn>anon17: What device are you installing Guix on?
<daviid>with no reason at all
<nckx>Please, that's not true. We explained the reason, you just don't like it.
<nckx>I'm not trying to get rid of you by pointing to the ML. We just don't make decisions like these on IRC.
<anon17>Cairn: i7-8750H x64 CPU laptop
<nckx>This is a (time-zoned) subset of an (IRC-using) subset of the community. Talking to 2 ‘random’ people won't build consensus even if we all agree. With that, I'll leave this subject be.
<Cairn>anon17: Yeah, that's a more recent laptop; the iso won't have the drivers for your device
<anon17>Cairn: i use asus laptop
<anon17>i see, any workaround you suggest?
<Cairn>You'll need to look for alternative channels. I was in your situation recently, want to PM?
<anon17>sure, i think i login to irc and get back to you..
<apteryx>nckx: about berlin; should we 'btrfs subvolume create /mnt/btrfs-pool-san/@cache' and proceed to 'rsync --delete -aPHAX /var/cache/ /mnt/btrfs-pool-san/@cache/' ?
<apteryx>we're down to just 149 GiB left on /var/cache
<nckx>What's the reason(s) it hasn't been done yet?
<apteryx>None, other than I thought you wanted to care care of it :-)
<nckx>Heh, and I thought I'd be stepping on your toeplans if I did. Whoops.
*nckx is in.
<apteryx>so, did you want to do it and then adjust the mounts? I happy if you do, but we need someone in charge :-)
<apteryx>OK, good
<apteryx>cool. Only recommendation is to run that from 'screen', it's probably going to take a long while (22 TiB)
<nckx>I dunno the throughput of this thing.
<nckx>My point, made.
<apteryx>also a 'time' would be nice
<apteryx>for curiosity
<nckx>Can do but I thought rsync printed that.
<nckx>Nothing wrong with both.
<apteryx>OK :-)
<apteryx>it should be relatively fast, because it's from electronic storage to electronic storage
<apteryx>actually I have no idea what kind of devices the SAN aggregates, but given the performance it's in the same league.
<nckx>apteryx: Just in case, I'd run with --delete-during unless you object.
<nckx>(That is safe, it just deletes files one by one instead of all at once after all 22T have been copied.)
*nckx expires arbitrary and unfair timer, begins transfer.
<apteryx>nckx: sorry, yes that's fine :-)
<nckx>Won't matter until it restarts, anyway, I guess.
<apteryx>so --delete-during is more efficient?
<apteryx>actually the first time we could have used just 'cp -a', since the destination is empty
<nckx>Sure, but I prefer rsync for this, and simply repeating the command if needed *shrug* matters little.
<nckx>cp -a would be fine indeed.
<nckx>The sun is doing that annoying thing again, and I have lunch to attend, so I need to 😴💤 soon. It's happily running. I'll check in one more time before lights out.
<nckx>Drives aren't as fast as I thought. ~200M/s average, for now.
<nckx>Ah, good news is that it seems to be limited by the I; the O happily spikes to >1G/s when needed! Whoo.
<Cairn>Physlock's unmaintained but stable. If I package it, would it get accepted? Or should I try to maintain it first?
<Cairn>For convenience:
<vivien>Commit 5a9c2abf9ecd47f4481c68cc5e57a85c84313645 is good, thanks! 👍
<florhizome[m]>Hey guix,
<florhizome[m]>how does guix normally install pulseaudio with desktop services and the gnome desktop service? I want to try to use pipewire but it seems I have to remove pulse from running. It’s not listed under shepherd services though although it appears to be in the %desktop–services list
<vivien>florhizome[m], it’s not in shepherd status here either, but it still works.
<vivien>(well I don’t know about pipewire)
<florhizome[m]>Zoom audio didn’t work for me
<florhizome[m]>It’s kind of weird that it seems to run but is not started by shepherd, isn’t it?
<vivien>Those things are incredibly brittle, did you try to reboot?
<vivien>It seems not to be started by shepherd
<florhizome[m]>After doing what?
<florhizome[m]>The gnome package contains pulseaudio, maybe it gets started over dbus?
<examors>"autospawn=no" in .config/pulse/client.conf prevents it for me
<florhizome[m]>yes it seems to be spawned by dbus
<florhizome[m]>this is just way too much magic
<florhizome[m]>i also changed the gnome package in gnome desktop service to replace pulse with pipewire and remove gnome boxes but seems like it did nothing
<florhizome[m]>gnome boxes is still there
<florhizome[m]>or maybe even by gdm
<florhizome[m]>It seems like various components of the gnome shell restart it
<rekado_>I see my name/nick here, so I feel the need to clarify: I wasn’t involved in packaging g-golf, as is clear from the git log. Nor do I recall making promises.
<rekado_>but I also don’t want to discuss this, because it seems rather petty.
<rekado_>I must say, though, that calling the actions of volunteers who made the effort of packaging your software (and thus making it more easily available) “offensive” is inappropriate.
<florhizome[m]>is someone reviewing
<unmatched-paren>PotentialUser-42: Hello
<PotentialUser-77>how do I customize guix kernel to include my wifi card, and then install
<PotentialUser-42>Hey everyone. Has anyone got Alacritty opacity on Guix system?
<unmatched-paren>PotentialUser-42: you'll need nonfree firmware, right?
<PotentialUser-77>lsmod shows iwlwifi is this my wifi card?
<unmatched-paren>you'll need an ath9k dongle/replacement card or the blobby kernel
<unmatched-paren>you can't discuss that on #guix though, the GNU police will get you :)
<unmatched-paren>s/that/the latter/
<PotentialUser-77>i see, suggest me what should I do if I want to install guix on my main machine?
<PotentialUser-77>Cant do with wifi right
<unmatched-paren>PotentialUser-77: Doesn't sound like anything related to Guix.
<unmatched-paren>Is it this issue?
<PotentialUser-77>unmatched-paren: when i boot into live install, my wifi interfact not showing up, I am stuck there..
<PotentialUser-42>unmatched-paren:  I thought, should I try to upgrade Alacitty package definition
<unmatched-paren>PotentialUser-42: I sent you a PM about nonfree firmware
<PotentialUser-42>Send to 77 not me
<unmatched-paren>Oh, do I have you two mixed up?
<unmatched-paren>My IRC client is cutting off your names :P
<unmatched-paren>Sorry :)
<PotentialUser-77>sry for confusion :)
<unmatched-paren>i guess PotentialUser is some default nick
<PotentialUser-42>Yeah I should register
<unmatched-paren>you don't need to register to use /nick
<PotentialUser-77>me too
<unmatched-paren>though registering stops people from hijacking your nick
<unmatched-paren>it basically gives you ownership of it
<unmatched-paren>but you can use any nick without registering it
<florhizome[m]>Should I write a mail about pulseaudio and pipewire? Will someone do something about it?
<PotentialUser-77>i see
<unmatched-paren>florhizome[m]: I have pipewire working
<unmatched-paren>you don't need any service
<unmatched-paren>i just start it in my sway.conf
<jpoiret>unmatched-paren: it's gnome messing around
<unmatched-paren>Ah, right
<jpoiret>not a pipewire issue per se
<florhizome[m]>I am using gnome atm
<unmatched-paren>I should have read the backlog before replying :)
<unmatched-paren>We *should* probably have a pipewire-home-service-type though
<florhizome[m]>A dbus / gnome /pulseaudio issue
*unmatched-paren scrolls backwards
<unmatched-paren>Cairn: Unmaintained packages are okay, I think
<unmatched-paren>So long as they aren't crawling with vulnerabilities
***PotentialUser-42 is now known as VesselWave
<PotentialUser-77>unmatched-paren : you were saying you will pm me :)
<unmatched-paren>PotentialUser-43: Looks like our Alacritty postdates the commit that adds background_opacity by a few years
<unmatched-paren>PotentialUser-77: yes, one moment :)
<florhizome[m]>The question is how you integrate it with regular desktop environments
<florhizome[m]>I am doing this also because I think guix should provide some basic functionality for normal users (or more). And because I acquired a newer laptop with touchscreen and large touchpad, so gnome is kinda nice^^
<florhizome[m]>afaik pipewire needs a dbus user service
<florhizome[m]>lol :D
<unmatched-paren>declan: oooh
<declan>You properly should check out rde project . There are some resources regarding Guix home.
<florhizome[m]>some guix people will need to care about DEs or this stuff (having recent stuff work) will never happen and guix will stay obscure.
<florhizome[m]>Declan yeah but does it work with gnome?
***Dynom_ is now known as Guest5339
<declan>Haven't seen any wrote a `home-gnome-service-type`, but pretty sure the idea is the same.
<jpoiret>florhizome[m]: I'm still trying to figure out how I want to use my touchscreen 3 years after I bought this laptop
<unmatched-paren>declan: The problem is that gnome seems to do something weird with pulse/pipewire
<unmatched-paren>nothing to do with services
<jpoiret>while big DEs have good oob support for touch controls, it's not customizable at all, but small wayland WMs don't seem to care about laptop/touchscreens that much either
<unmatched-paren>jpoiret: Looks like there was some hacky effort to add a `touch` command to sway
<unmatched-paren>but the developer abandoned it
<unmatched-paren>jpoiret: Also, this thing apparently kinda works with xwayland:
<declan>touchpad or touchscreen?
<unmatched-paren>Oh, right
<unmatched-paren>libinput-gestures is for touchpad, oops
<jpoiret>i don't like libinput-gestures that much. But the main issue is that I'm finding the simple sway workspace system to not be enough for my needs
<unmatched-paren>(I think?)
<jpoiret>i think it should work with touchscreen too, i'm not sure
<jpoiret>at least libinput should provide the same amount of data
<florhizome[m]><declan> "Haven't seen any wrote a `home-..." <- Well I’m totally here to promote it though I think some stuff (polkit registrations) will have to stay system service. But with separate profiles for a DE.
<anhj>hello there!
<florhizome[m]><jpoiret> "florhizome: I'm still trying..." <- I even have a pen :D
<florhizome[m]>well it comes handy if you use it for reading etc or on the road. I actually wrote a service to enable screens rotation and power management in gnome.
<unmatched-paren>anhj: hi :)
<florhizome[m]>for xorg there was a “touchegg” service for defining touch gestures
<florhizome[m]>there doesn’t seem to be a wayland/wlroots equivalent so far
<florhizome[m]>hi anhj!
<florhizome[m]>I only know about wayfire and the developer there is too busy refactoring.
<anhj>just a few words of intro, I don't want to interrupt. I just installed the guix package manager on a foreign distro (debian, FWIF) and starting slowly to discover it
<unmatched-paren>anhj: You aren't interrupting anyone :)
<anhj>unmatched-paren: ok, thank you :)
<jpoiret>florhizome[m]: i've got one too! It's a 2-in-1 i got for manual note taking (latex is fine but not really useful for actual thinking :p) and also to use in general
<jpoiret>I wish i could easily group apps dynamically based on what i need, for example be able to bring up an article i'm reading next to my notes only when i need it
<me23>Hi ! Which version of gcc-toolchain is needed to ./configure before testing packages for ./pre-inst-env ?
<me23>I get the following error : checking whether the C compiler works... no and logs related to -V and -qversion outdated gcc options
<anhj>I just noticed a minor annoyance at the end of the installation process: tries to symlink the info files in /usr/local/share/info. On my computer, that directory existed already, and had a "dir" index file. The symlink of the index file provided (same name "dir") failed, and that stopped the whole symlink loop. As "dir" was the first one in the loop (d is before g...), no info file was symlinked at all.
<anhj>thus I has to do it manually, and they do not appear in the index file (which is not a problem for me, I know they exist and where to find them)
<anhj>I hope my somewhat convoluted explanations are clear :)
<unmatched-paren>i don't know much about info, but surely there's a way to rebuild `dir`?
<unmatched-paren>after adding the new info files
<unmatched-paren>ohh, the `texinfo` package provides an `install-info` program for that
<anhj>yes, but it cannot do it for all files in one pass
<anhj>so I suppose the install script should call it in the loop
<jpoiret>me23: are you providing the dependencies via guix?
<unmatched-paren>anhj: <- is here, could you send a patch to use install-info?
<anhj>not sure I can do that, but at least I could file a bug report I suppose
<jpoiret>If so, just `guix shell -D guix` should be enough
<me23> I'll try, thanks !
<anhj>unmatched-paren: I will try and do my best
<unmatched-paren>anhj: All you need to do is clone the repo, create a commit for the change following changelog conventions, and `git send-email -1`
<unmatched-paren>the commit message will probably be `etc: Use install-info.` or something
<anhj>unmatched-paren: noted, I meant that I am not sure I can patch properly though :)
<unmatched-paren>and the body `* etc/
<unmatched-paren>and the body `* etc/ Use install-info to install the manual.`
<unmatched-paren>I see.
<anhj>I'll try anyway
<unmatched-paren>It shouldn't be too hard
<unmatched-paren> <- here
<unmatched-paren> <- in this function
<anhj>yes, I found it already :)
<me23>works, thanks jpoiret ;)
<declan>anhj: I thought debian has Guix packed. Why not `apt install guix` `guix pull` instead.
<unmatched-paren>declan: debian's guix is very old
<lilyp>florhizome[m]: ironically, you could make this a global change by using the pulseaudio-service-type
<anhj>declan: yes, it is old, and I had a look at it and it makes some changes/choices which led me to prefer the vanilla guix
<lilyp>pulseaudio-service-type only provides the pulseaudio configuration, it does not cause the daemon to launch (that is handled by dbus as already pointed out)
<declan>unmatched-paren: `guix pull` should pull the latest, right?
<unmatched-paren>declan: i guess
<unmatched-paren>it can sometimes cause search path issues where the debian guix takes priority, seemingly
<florhizome[m]><lilyp> "florhizome: ironically, you..." <- ah thanks I’ll try
<rekado_>florhizome[m]: please do discuss this on the mailing list. It’s not acceptable for users to have to use “guix home” to get Gnome working.
<rekado_>whatever we can automate to make installation of DEs easy should be automated
*rekado_ reviewed 57257
<rekado_> doesn’t seem to be updating
*rekado_ restarted the sync
<florhizome[m]>lilyp: seems to work, when running pipewire off the cli :)
<lilyp>florhizome[m]: now you only need to autostart pipewire, e.g. from shepherd or gnome-autostart
<florhizome[m]>rekado: guix home is not automation?
<florhizome[m]>yes I will try the above mentioned shepherd-home-service
***toluene9 is now known as toluene
<rekado_>florhizome[m]: “guix home” is a separate step. Currently, we can fully specify an OS with an operating-system record.
<rekado_>if “guix home” is the only way we’d need more integration with operating-system and “guix home”.
<unmatched-paren>It would be nice to have a (home-configuration FILE-LIKE-OR-HOME-ENVIRONMENT) field in <user-account>...
<unmatched-paren>But my Guix todo list is filling up quite quickly :)
<unmatched-paren>* better error messages for network disconnection
<unmatched-paren>* home-configuration field for <user-account>
<unmatched-paren>* post-install notes for packages
<florhizome[m]>But a DE is not necessarily part of an OS.
<florhizome[m]>as far as I see it we will need to leave some services that are in Gnome desktop right now, mainly polkit stuff.
<florhizome[m]>but you would need this for any service.
<florhizome[m]>*user service.
<unmatched-paren>Hmm, if we had a (home-configuration ...) field for <user-account>, could we make `guix home` the default? :P
<unmatched-paren>As in, set up `guix home` for users in the default system configuration.
<florhizome[m]>You can just write your home config in the same file as the system can’t you?
<rekado_>unmatched-paren: yes, maybe. It should probably not be more than extending a minimal configuration that users can further extend.
<unmatched-paren>florhizome[m]: Yes, exactly, if this feature is implemented, you only need one file.
<unmatched-paren>And you can already use the channels-home-service-type for the channels instead of writing a channels.scm.
<rekado_>users many not be able to modify the operating-system config, so it must work as an extension
<florhizome[m]>but if I have a home environment record in a file guix home command will read it out right? or I give it some name and pick it with the - eflag
<unmatched-paren>that's a good point
<unmatched-paren>florhizome[m]: yeah
<florhizome[m]>start the user dbus, pipewire, … that’s it
<florhizome[m]>a user should be able to install multiple DEs imo that’s more of a problem maybe, at least for us to do testing
<unmatched-paren>florhizome[m]: Huh, that's not currently possible?
<florhizome[m]>I’m having a meal now.
<florhizome[m]>right now we don’t have user DEs is what I’m saying
<unmatched-paren>How do I get rid of this irritating `pls accept dir-locals` popup? I can't press `!` because then it tries to mutate .emacs, which doesn't work since it's managed by Guix Home.
<declan>Are you manage Emacs =custom-file= in Guix?
<unmatched-paren>I'm not sure what `custom-file` is. I'm pretty new to Emacs :)
<mrvdb>How should I interpret this error: This shows when I try to start virt-manager (not installed by guix). sudo virt-manager works
<unmatched-paren>mrvdb: This Python3 from not-guix is trying to load from guix
<unmatched-paren>which probably won't work due to various black magicks guix does with binaries
<unmatched-paren>not sure how you'd point it in the right direction though...
<declan>unmatched-paren: Put code here in your emacs config. You can lookup =custom-file= using =C-h v custom-file= in Emacs
<unmatched-paren>declan: thanks
<unmatched-paren>rekado_: I've sent a patch to fix the GUIX_EXTENSIONS_PATH issue. Is this an adequate solution?
<unmatched-paren>It definitely works; I've tested it with ./pre-inst-env guix install gwl && less ~/.guix-profile/etc/profile.
<unmatched-paren>But I'm wondering if it isn't the most elegant and Schemey way to solve the problem...
<lilyp>unmatched-paren: no, it's not
<lilyp>You could add $GUIX_EXTENSIONS_PATH to manifest-search-paths, but even that is exaggerated imho.
<unmatched-paren>lilyp: Hmm, are you replying "no" to "is this an adequate solution?" or "is it the most elegant way?"
<lilyp>I think it is both inadequate and inelegant.
<unmatched-paren>I'll try to find a better way then.
<lilyp>The way to handle search paths is with search-paths.
<rekado_>unmatched-paren: I think it’s not bad, but it also falls short. It’s a search path, so it shouldn’t be limited to the current profile.
<unmatched-paren>Hmm, would this be okay? `(define %implicit-search-paths (list $PATH $GUIX_EXTENSIONS_PATH))` and s/(cons $PATH/(append %implicit-search-paths/
<rekado_>mrvdb: it’s not so much what Guix does to the binary, it’s just that you cannot load binaries with different ABI and expect them to work correctly.
<rekado_>the system Python probably loads the .so file, because there’s a search path for typelibs.
<rekado_>that search path was set by Guix, but it is respected by any Python — whether from Guix or not.
<rekado_>we had the same problem with PYTHONPATH, so eventually we made our Python from Guix respect GUIX_PYTHONPATH, so that a foreign Python would not be affected
<rekado_>the same argument could be made for things like GI_TYPELIB_PATH, XDG_DATA_DIRS, etc
<rekado_>mrvdb: to work around this you may want to look at the output of env first and then evaluate “unset” for any suspicious environment variable, starting with GI_TYPELIB_PATH.
<mrvdb>rekado_: allright, trying that (i've been trying some other to no avail)
<mrvdb>Yay! unset GI_TYPELIB_PATH does the trick
<mrvdb>so, the main problem is that both guix and foreign share some env variables which leads to conflicts
<unmatched-paren>mrvdb: <- Looks like this will be fixed by a fix for your bug, too
<mrvdb>thanks, the knowledge on which VAR too massage is a sufficient workaround for me right now.
<mrvdb>i wish I could put myself on a cc list for bugs, or am I missing something? (i would have never matched the title of that issue to my problem myself)
<lilyp>unmatched-paren: I don't think we need those implicit paths anywhere outside manifest-search-paths, so just insert $GUIX_EXTENSIONS_PATH on an extra line after $PATH
<unmatched-paren>lilyp: Okay, thanks
<ardon>Hi Guix! What's the most sensible way to get a file server with WebDAV support running in Guix? I've thought of building nginx with the WebDAV module but I'm unsure if there's a more optimal alternative
<unmatched-paren>lilyp, rekado_: v2 that does things properly:
<unmatched-paren>This still won't allow channels to include extensions, but it's a start :)
<lilyp>unmatched-paren: actually, it will allow channels to include extensions, but you'd need to write a package for that extension in the channel
<unmatched-paren>Yes, that's what I men
<lilyp>which imho is a cleaner design anyway
<unmatched-paren>It would be ideal if a channel could include a guix/extensions directory though, imo
<unmatched-paren>directly include it
<lilyp>I think it's better to opt into this extension
<lilyp>you can also make a channel ship multiple extensions that way
<unmatched-paren>huh? they could just put several scripts into guix/extensions, no?
<unmatched-paren>Good point about opting in, though.
<lilyp>yes, but let's say you were to open up "unmatched paren extensions" and I'd want to use only the ham extensions but not the spam one
<lilyp>that kind of thing
<unmatched-paren>Now, back to thinking of an elegant solution for `guix install guix` :) Now that the GUIX_EXTENSIONS_PATH issue is fixed, I see no need for general post-install notes, so that idea can be discarded...
<unmatched-paren>I honestly don't really see the problem with `(define (filter-guix-package packages) (filter-map (lambda (pkg) (match (package-name pkg) ("guix" (display-warning "skipping Guix package (<explanation of why>)" #f) (_ pkg))) packages))` but apparently Tobias rejected such a solution.
<unmatched-paren>The Guix package *is* special, so I don't understand why we can't special-case it.
<unmatched-paren>Special because it is, as far as I can see, the only package that isn't hidden that should never be installed.
***Dynom_ is now known as Guest4811
<unmatched-paren>Or, the only package that could reasonably be `guix shell`ed but not `guix install`ed or `guix (system|home) reconfigure`ed.
<unmatched-paren>I thought about (removed-from-install-package "<warning>" (package ...)) but that seems like overgeneralization, as `guix` is the only package that would conceivably use it.
<unmatched-paren>Same for post-install notes.
*acrow waves at vagrantc
<unmatched-paren>nckx: If you're there, why did you reject (IIRC) the idea of doing something like for `guix install guix`, when checking against the (package-name) of each package is perfectly robust, and any other solution would probably only really apply to the `guix` package itself?
<grobx[m]>I'm trying to run some haskell code in guix shell using runhaskell, but it works only if I install also the gcc package.... (full message at
<unmatched-paren>grobx[m]: I think this has been reported before
<grobx[m]>ok thank you unmatched-paren, I'll dig into the issues
<unmatched-paren>We could try to patch the GCC invocation in the GHC source to use the absolute path
<unmatched-paren>nckx: We could fix this problem for `guix home`, for instance, by adding (sanitize filter-guix-package) to the definition of <home-environment>'s packages field.
<unmatched-paren>nckx: Same for <operating-system>. And for `guix install`, in guix/scripts/package.scm (options->installable), wrap to-install in (filter-guix-package ...).
<grobx[m]>> We could try to patch the GCC invocation in the GHC source to use the absolute path
<grobx[m]>sorry, what do you mean?
<unmatched-paren>grobx[m]: We could add a build phase to the GHC package that replaces the code that calls GCC (maybe something like `exec $ "gcc":args`, idk) with something like `exec $ "/gnu/store/.../bin/gcc":args`
<grobx[m]>ok now I see; will this solve the issue also in pure shell?
<grobx[m]>that would be great. I dont know how to proceede, but I can tell you that ghc@8.6.5 is not affected by this issue, while ghc@8.4.4 and ghc@8.10.7 are
<unmatched-paren>oh, interesting
<Guest141>I'm trying to move /gnu/store to another drive.  While mv copies the files just fine, it is unable to delete the originals after the fact (says read only filesystem).  Any idea how I can delete those files and get back that drive space?
<unmatched-paren>Guest141: umount the store and remount it rw iirc
<Guest141>unmount?  df doesn't show /gnu or /gnu/store mounted, so I don't know how to unmount it
<unmatched-paren>i think `umount /gnu/store` should work...
<unmatched-paren>though i'm not sure how to remount it
<sneek>Welcome back nckx!
<Lumine>Good evening!
<unmatched-paren>Lumine: hello!
<Guest141>unmatched-paren: weird, it doesn't show in df, but umount store says "target busy"...
<Lumine>unmatched-paren: hurro
<unmatched-paren>Guest141: Sorry, I'm not too sure how you'd do this :/
<unmatched-paren>I know it's possible though
<Guest141>no worry, you sort of answered my question
<unmatched-paren> <- but i can't find the exact command :/
<unmatched-paren> <- oh!
<unmatched-paren>mount -o remount,rw /gnu/store
<Guest141>THAT DID IT.  I still have questions, like how mount knows how to mount store without an fstab entry, but everything works now anyway
<Guest141>Thanks a ton!
<unmatched-paren>Guest141: Looks to be mentioned in /etc/mtab
<Guest141>interesting.  Will need to do more reading
<unmatched-paren>I have no idea what it means either -.o.-
<unmatched-paren>But it seems like both / and /gnu/store are somehow on the same partiton
<unmatched-paren>my /dev/nvme0n1p1 contains them both
<Guest141>Yeah, I see that.  would make sense if btrfs, but it's ext4...
<Guest141>And just like that MY PINEPHONE LIVES
<unmatched-paren>Oh, you're running guix on your pinephone!
<unmatched-paren>Nice! :D
<Cairn>Hey. I'm building up the courage to send my first patches. Does Guix use that "signoff" feature in git send-email?
<unmatched-paren>Cairn: Nope
<unmatched-paren>It's used to identify the committer
<rhumbs>hello. I'm trying to make a guix rust package with the help of the `guix import crate` command but I don't understand how the rust dependencies in "cargo-inputs" are managed
<Cairn>unmatched-paren: Fair enough, thanks
<rhumbs>I've described my problem here
<unmatched-paren>A commit to the repo will have author: <person who sent the commit> and signed-off-by: <person who pushed the commit>
<rhumbs>anyone has experience on that ?
<unmatched-paren>rhumbs: well, the package depends on byteorder v1.*, and guix doesn't have that package yet
<Cairn>unmatched-paren: Could I ask you specifically how you did your patchset email for the aerc patches? Did you just send an email with "[PATCHSET]" in the title?
<unmatched-paren>Cairn: I did, but it's better to use --cover-letter
<unmatched-paren>i didn't know about that feature when I sent aerc
<Cairn>Got it. I'll look into that.
<unmatched-paren>What you do is `git format-patch --cover-letter -o outgoing -<number-of-patches> -a`
<unmatched-paren>then edit the cover letter and the patches however you want
<Cairn>Hm, alright!
<Cairn>I'm gonna mess this up and it'll be in the mailing list forever 😅
<unmatched-paren>next, `git send-email outgoing/0000-<cover-letter-name>`
<unmatched-paren>delete the cover letter
<unmatched-paren>wait for an ack from debbugs
<unmatched-paren>and then `git send-email outgoing/*.patch --to=<bug-number>`
<unmatched-paren>Debbugs sadly isn't smart enough to know that the patches should all be merged into one thread
<unmatched-paren>if it was, you could just do `git send-email -<number-of-patches> -a`
<unmatched-paren>but if you do that it'll create one new bug for each patch
<rhumbs>@unmatched-paren ah ok, thank you
<Cairn>Hm, that makes sense... Gonna get some food, but I'll probably ask some nervous questions while I'm in the process haha
<unmatched-paren>rhumbs: btw, you won't get many answers if you ask about guix on SO
<unmatched-paren>always ask here or in
<unmatched-paren>rhumbs: two other things:
<unmatched-paren>* you don't need to @ people on IRC, just mention their name
<unmatched-paren>* you can use `guix import crate -r` to fetch all the dependencies
<rhumbs>unmatched-paren noted thank-you :)
<unmatched-paren>(I'm not sure whether this also includes packages that are already in guix though, be careful; also, if you're planning to send a patch, you should break the patchset into one commit per patchset)
<unmatched-paren>s/per patchset/per patch/
<unmatched-paren>s/a patch/a patchset/
<Cairn>Yeah, I'm doing one commit per package I add/update
<unmatched-paren>Cairn: I was talking to rhumbs there :)
<Cairn>Excuse me 🤦
<rhumbs>unmatched-paren `guix import crate -r` fetches some other crates, but not byteorder. I'll try to do it manually
<unmatched-paren>rhumbs: Wait, we already have rust-byteorder-1.
<unmatched-paren>Do you not have (gnu packages crates-io) imported?
<rhumbs>unmatched-paren no it was not imported. I added it and it fixed the byteorder error. Thank you!
<rhumbs>I missing imports on other dependencies but I think I know where to look now
<unmatched-paren>(gnu packages crates-io) contains almost every Rust library in Guix
<unmatched-paren>there's also (gnu packages crates-graphics)
<unmatched-paren>which might contain something you need
<rhumbs>ok. I need to look at those modules. I'm only two days in guix so a lot to learn..
<unmatched-paren>All the packages are in (gnu packages *), which corresponds to gnu/packages/*.scm in the source repo
<Cairn>I'm adding go dependencies, and I don't see in the manual if it matters where in the file I add packages. Should I just add them to the bottom of the file?
<unmatched-paren>Try to keep related packages close together.
<unmatched-paren>But other than that, probably yes.
<Cairn>So I'll find related packages and add solitary ones to the bottom?
<rhumbs>package is building, crossing fingers...
<cassio>could anyone help me to understand why this ↓ doesn't work?
<unmatched-paren>cassio: put code on btw
<unmatched-paren>(just in case you were about to paste code into the channel :))
<Cairn>Is that * line which reiterates the update manually written?
<unmatched-paren>Cairn: Yes
<rhumbs>success! thank you for your help ummatched-paren !
<unmatched-paren>ChangeLog is dumb but required in commit messages
<Cairn>Alright, I'll update my commits to use it
<Cairn>I didn't quite understand what the ChangeLog thing was about, but I guess now I know
<cassio>Having trouble reconfiguring with my home-configuration.scm ─ could anyone help me to understand why this ↓ doesn't work?
<cassio>(simple-service 'this-environment-variables-service
<cassio>                      home-environment-variables-service-type
<cassio>                      `(("EDITOR" . ,(file-append nvim "/run/current-system/profile/bin/nvim")))
<unmatched-paren>cassio: I just told you to use :(
<unmatched-paren>Doesn't matter. It's not too long.
<unmatched-paren>Your problem is that file-append returns a g-expression.
<unmatched-paren>Hmm, actually, is environment-variables supposed to be able to take a file-like?
*unmatched-paren checks
<unmatched-paren>I'm not sure it is.
<unmatched-paren>cassio: Can you put the error message you get on
<cassio>@unmatched-paren: I just adapted an example from the users' manual:
<cassio>(simple-service 'some-useful-env-vars-service
<cassio>  home-environment-variables-service-type
<cassio>  `(("LESSHISTFILE" . "$XDG_CACHE_HOME/.lesshst")
<cassio>                  ("SHELL" . ,(file-append zsh "/bin/zsh"))
<cassio>                  ("USELESS_VAR" . #f)
<cassio>                  ("_JAVA_AWT_WM_NONREPARENTING" . #t)))
<unmatched-paren>please please please please use
<unmatched-paren>hmm, yes, you should be able to
<unmatched-paren>silly me
<unmatched-paren>nvim isn't defined
<unmatched-paren>you should use `neovim` instead
<unmatched-paren>after importing (gnu packages vim)
<unmatched-paren>Also, you don't need to @ people on IRC, just say their name: cassio
<cassio>Thanks, unmatched-paren, for all the tips (sorry I didn't use It worked ─ reconfiguration is under way right now!
<unmatched-paren>can't you just set EDITOR to `nvim` though?
<unmatched-paren>no need for file-append
<unmatched-paren>assuming you have neovim in your packages of course ;)
<unmatched-paren>How can I tell Emacs to load newly installed packages without restarting it?
<unmatched-paren>guix-emacs-autoload-packages doesn't seem to work
<jab>cassio: you're a neovim guy!? Cool!
<Cairn>You could evaluate them manually
<Cairn>Although if it's a lot of packages, that's probably annoying
<unmatched-paren>Cairn: Yes, that's what I'm doing now
<unmatched-paren>it's only two, fortunately
<Cairn>Ah, hm. Not sure of a better way.
<unmatched-paren>it probably shouldn't be too hard for guix-emacs to implement such a reload featuer
<Cairn>When I run guix lint, I get two lines about my git url. Should I not use ".git" at the end?
<unmatched-paren>no, you shouldn't
<Cairn>Noted. On the same line I get a message that says "scheduled Software Heritage archival"
<Cairn>Is that something I need to handle?
<Cairn>The linter's warning me about a project without tags and releases. Nothing to be done about that, right?
<unmatched-paren>Cairn: (1) No (2) Yes
<unmatched-paren>Software Heritage is a software archiving site
<unmatched-paren>nooo, emacs-lua-mode fails its tests :(
<cassio>jab: Yes, I've chosen `neovim`. But I'm just starting to learn how to work with it...
<cassio>In fact, I would love to know how to manage neovim plugins declaratively in Guix ─ could you help me with that?
<unmatched-paren>cassio: There aren't many neovim plugins in Guix yet
<unmatched-paren>But there are a few in Guix 'R Us that I should upstream at some point...
<unmatched-paren>All you need to do is add the loading stuff to your config file and add the plugin package to your packages list
<Cairn>So guix lint automatically archives the software? Kinda cool.
<unmatched-paren>Cairn: Yep! :D
<unmatched-paren>And Guix falls back to SWH if the usual source code host is down.
<Cairn>Oh cool!
<Cairn>Whew. I committed all my changes to a branch.
<Cairn>Now the scary part is git send-email
<unmatched-paren>And git format-patch :)
<unmatched-paren>It's not really too hard.
<unmatched-paren>You use -<n> to send the last n commits.
<unmatched-paren>e.g. -3
<unmatched-paren>-a opens up your editor to review the commits one last time and add blurbs.
<Cairn>Oh, so I won't need to use git send-email for each commit? I'll just send them all with one command?
<unmatched-paren>--cover-letter adds a summary. You need to annotate it with a subject and blurb.
<unmatched-paren>Cairn: That would be the case for a sane mailing list host like, but sadly debbugs isn't too clever
<unmatched-paren>you need to first create the cover letter
<Cairn>Ok one sec
<unmatched-paren>s/cover letter/cover letter and patches/
<Cairn>I've got a cover letter written up.
<unmatched-paren>no, the cover letter is autogenerated
<unmatched-paren>you need to write a description for it though
<unmatched-paren>do this:
<unmatched-paren>$ git format-patch -o outgoing -<num-commits> -a
<unmatched-paren>$ git format-patch -o outgoing -<num-commits> -a --cover-letter
<Cairn>Do I need to merge my commits back to the master branch first? I assume it doesn't matter.
<unmatched-paren>this will put the patches and the cover letter in the outgoing directory, and open up your editor to modify them
<unmatched-paren>Cairn: No, you don't.
<unmatched-paren>when you quit the editor, the patches will be saved
<unmatched-paren>then you do
<unmatched-paren>$ git send-email outgoing/0000-<cover-letter-name>
<unmatched-paren>$ git send-email outgoing/0000-<cover-letter-name>
<jab>cassio: I'm a doom emacs guy. :)
<unmatched-paren>this will send your cover letter to the mailing list
<cassio>unmatched-paren: you tell me there are not many neovim plugin packages in Guix ─ does that mean that these few packages are the only ones I can use in Guix? Or is there a workaround
<Cairn>My cover letter description that I've written is similar length to the first email you sent in the aerc patchset. That's not too large in this case, right?
<jab>unmatched-paren: there's also git send-email --annotate option.
<unmatched-paren>cassio: You can write packages for them
<unmatched-paren>jab: -a == --annotate
<unmatched-paren>Cairn: Nope.
<unmatched-paren>Just replace that *** blurb here *** text with your text.
<unmatched-paren>And remember to change the subject line.
<Cairn>Alright. Let me follow these steps then. I'll be back once I've sent my cover letter.
<unmatched-paren>cassio: Have a look through
<unmatched-paren>Cairn: After you do that, wait for the debbugs mailer to reply
<unmatched-paren>the reply should contain a bug number
<unmatched-paren>(this is an "ack" == "acknowledgement")
<unmatched-paren>now you rm the cover letter
<unmatched-paren>and do this for the rest of the emails:
<unmatched-paren>$ git send-email outgoing/*.patch --to=<BUG-NUMBER>
<unmatched-paren>once they're sent, you can rm the outgoing dir
<unmatched-paren>In a smarter git email system, you could just do this:
<cassio>unmatched-paren: will do, thanks
<unmatched-paren>$ git send-email -a --cover-letter -<num-commits>
<unmatched-paren>to send them in one command
<unmatched-paren>e.g. that's how you send patches to sourcehut
<apteryx>wow, latest polkit uses duktape by default
<Cairn>Alright, I'm not quite there yet. I don't need to modify any of the patches other than the cover letter, right? At least if I'm happy with them?
<Cairn>I tried to be thorough the explanation in the cover letter.
<unmatched-paren>Cairn: Unless you want to add an extra explanation to the commit, no, you don't need to modify them.
<Cairn>Alright. Gonna try the sendmail then
<unmatched-paren>apteryx: Do they *WANT* someone to make a simpler alternative that everyone who cares about software bloat will flock to? Because that's what happened with logind.
<Cairn>I did it, I sent the cover letter
<Cairn>Waiting for that response =)
<unmatched-paren>woot :)
*Cairn dances while waiting
<unmatched-paren>Hmm, it should have arrived in your mailbox by now.
<unmatched-paren>It might take a little longer to show up on though.
<Cairn>unmatched-paren: Reponses have been slow for me in the past. Not sure why.
<jab>unmatched-paren: there's also I pretty much refer to that most of the time....
<unmatched-paren>jab: is nice, but doesn't warn you about the issues with debbugs (since it's a general guide)
<unmatched-paren>also, it doesn't tell you about `-<n>` ;)
<unmatched-paren>nor --cover-letter.
<jab>unmatched-paren: true dat!
<jab>unmatched-paren: maybe we should have an specific emacs command to shell out to git send-email....
<jab>but magit may already have that...
<unmatched-paren>magit doesn't have such a feature yet iirc
<shcv[m]>any recommendations on how to improve power usage for guix on a laptop?
<unmatched-paren>probably because most people will just use emacs-forge with GitHub™®
<unmatched-paren>shcv[m]: I use tlp-service-type and thermald-service-type
<unmatched-paren>I have no idea how much they actually help tho :)
<unmatched-paren>I have noticed that my laptop is a lot cooler and quieter since adding them tho.
<shcv[m]>well, stock was saying I only had 4 hours, which is about half what I was hoping for
<jab>unmatched-paren: Not me! :) I'm a notabug fan...though I should probably just go ahead and pay for sourcehut. That is an awesome open source business.
<unmatched-paren>jab: The alpha is free, but paying is recommended
<unmatched-paren>because free access will be removed in beta
<unmatched-paren>Quite impressive how rock-solid it feels despite being in alpha.
<Cairn>Yeah, "alpha"
<Cairn>Feels better than most other services already
<Cairn>(in my limited experience, haha)
<jab>unmatched-paren: I want to support free software businesses. :) already pay for
<jab>actually the guys, told me that they have a goal to package all of their dependencies in guix!
<unmatched-paren>nice :)
<Cairn>TIL about
<pkill9>i paid for sourcehut
<jab>Cairn: it's really cool. :)
<jab>pkill9: paid? or paying?
<pkill9>i paid for the year
<pkill9>20 quid
<pkill9>idk if there is even any benefits
<pkill9>but oh well, i like it so i support it with my wallet
<unmatched-paren>pkill9: I believe CI is paid-only
<jab>pkill9: God bless your tender soul! haha
<shcv[m]>jab: not to go too far off topic, but what do you use for?
<unmatched-paren>because they had too many fakemoney miners abusing the CI
<unmatched-paren>they restricted it to paid users
<pkill9>unmatched-paren: yeah i think that is yeh
<unmatched-paren>The CI is pretty great.
<pkill9>yes it's nice
<jab>shcv[m]: I have a pinephone. I have two phone numbers that cost me a total of $13 per month. I use the number for my friends.
<rekado_>pkill9: I don’t know why but I read “my wallet” as “my mullet”, and I thought for a moment that the 80s had returned.
<pkill9>and they have a guix image
<unmatched-paren>pkill9: yeah!
<shcv[m]>rekado_: they never truly left
<jab>I actually use my laptop with my number. I have not figured out how to make calls via on my pinephone...
<unmatched-paren>nice that the community can maintain quasi-official things like that
<pkill9>rekado_, the 80s is returning
<unmatched-paren>It will be the 80s again in approximately 60 years.
<jab>shcv[m]: If you have any other questions, I invite you to message me directly. :)
*Cairn still waiting, still dancing
<unmatched-paren>Cairn: Hmm, that's pretty weird. What command did you run to send the email?
<Cairn>`git send-email outgoing/0000-cover-letter.patch`
<Cairn>And then I watched the output from my smtp and it said sent
<unmatched-paren>that should work fine...
<Cairn>And then I checked my online web host and it says it's sent
<unmatched-paren>i guess you can just keep dancing then
<Cairn>You got it! 🤟
<Cairn>Oh oops
<Cairn>I guess both
<unmatched-paren>Hand dance.
*unmatched-paren away
<nckx>Cairn: Savannah's been under DDoS lately. It might be related, or just a random delay. Those do happen.
<nckx>I can say that you're not in the moderation queue.
<Cairn>nckx: I've had a delay for most of the mails I've sent to the mailing lists. Not a big deal. I'm just excited to get this patch submitted =)
<nckx>Fame and Lambos await.
<nckx>unmatched-paren: Questions noted.
*nckx away for now.
*jonsger[m] finds it a bit odd when a Warning (of Guix) during `guix build` becomes an error (drv could not built) during `guix pull`...
<pkill9>have there been any security issues with servers running guix system?
<grobx[m]>Anyone know why guix home says "\guix home: warning: cannot determine provenance for current system" on my foreign distro?
<grobx[m]>s/guix home/guix home reconfigure
***rgherdt_ is now known as rgherdt
<jab>nckx: how often does it get DDos-ed?
<jab>grobx[m]: that warning you can safely disregard.
<grobx[m]>thanks jab
<jab>yup. :)
<nckx>Cairn: Your message just stumbled into the moderation queue, drunk and smelling of several brands of cheap perfume. You might want to have words with it. But you should have got that bug number now. Let me know if you didn't.
<nckx>jab: Not that often, I think the last time it happened was (very!) roughly about a year or so ago.
<nckx>The current wave might even be over by now. I only know it lasted a few days at least.
<jab>nckx "smelling of several brands of cheap perfume." haha
*nckx 'fkay 'gain.
<isf>Hello, is in GNU Guix manuals in spanish?
<isf>I want learn more about how GNU works, but several manuals are in english, and isnt my native lenguage. Someone know more information about this topic? Or if exist a group of users who work for translation team of GNU Guix? Thanks
<grobx[m]>isf: it should be this