<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>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>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 <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>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 <nckx>I'd have to read vm.scm with a lot more attention than I can currently spare, sorry :) <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. <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>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>I know I can deploy on the machine, I just don't know how to configure network in a '"guixy' way <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>or info '(guix) Networking Services' <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 <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? <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? <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. <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… <Cairn>nckx: Wow, I didn't know about that search <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 ... <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. <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, https://hpc.guix.info/browse 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 <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 <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. <daviid>let me paste an org example ofwhat imean <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). <Cairn>Ah, sorry, I was impatient, haha <Cairn>Alright, I'll try to keep an eye out then. Thank you! =) <Cairn>Packaging is hard. Seems like everything I want to package needs a fix upstream before I can submit a patch. 😢 <nckx>Humph, now I find a second instance of what is clearly the same script with sliightly different CSS, looks a lot better: https://guix.mdc-berlin.de/ (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. <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. <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’. *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). <Cairn>But yeah, I'm still curious why we wouldn't just use prefixes <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 <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>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. <nckx>It's not more offensive to prefix than to suffix, surely. <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. <anon17>live, manual install, wifi interface not found, when I type ip address.. please suggest.. <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 <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>well i am sorry, my package name was changed without my authorization <Cairn>anon17: What device are you installing Guix on? <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. <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>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. <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>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>Can do but I thought rsync printed that. <nckx>Nothing wrong with both. <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. <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? <vivien>Commit 5a9c2abf9ecd47f4481c68cc5e57a85c84313645 is good, thanks! 👍 <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]>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]>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]>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]>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. <PotentialUser-77>how do I customize guix kernel to include my wifi card, and then install <unmatched-paren>you can't discuss that on #guix though, the GNU police will get you :) <PotentialUser-77>i see, suggest me what should I do if I want to install guix on my main machine? <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 <florhizome[m]>Should I write a mail about pulseaudio and pipewire? Will someone do something about it? <jpoiret>unmatched-paren: it's gnome messing around *unmatched-paren scrolls backwards ***PotentialUser-42 is now known as VesselWave
<unmatched-paren>PotentialUser-43: Looks like our Alacritty postdates the commit that adds background_opacity by a few years <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]>some guix people will need to care about DEs or this stuff (having recent stuff work) will never happen and guix will stay obscure. ***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 <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 <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 <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. <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. <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]>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 <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: guix-install.sh 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>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? <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 <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 --to=guix-patches@gnu.org` <unmatched-paren>the commit message will probably be `etc: guix-install.sh: 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/guix-install.sh: Use install-info to install the manual.` <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. <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>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_>issues.guix.gnu.org doesn’t seem to be updating *rekado_ restarted the sync <lilyp>florhizome[m]: now you only need to autostart pipewire, e.g. from shepherd or gnome-autostart ***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>... <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. <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 <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>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? <mrvdb>How should I interpret this error: https://dpaste.org/xGDKL 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 libgdk.so from guix <unmatched-paren>which probably won't work due to various black magicks guix does with binaries <declan>unmatched-paren: Put code here https://bpa.st/XWYA in your emacs config. You can lookup =custom-file= using =C-h v custom-file= in Emacs <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. <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 <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 <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>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 <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 <lilyp>I think it's better to opt into this extension <lilyp>you can also make a channel ship multiple extensions that way <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 <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. <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 <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 <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? <Guest141>unmount? df doesn't show /gnu or /gnu/store mounted, so I don't know how to unmount it <Guest141>unmatched-paren: weird, it doesn't show in df, but umount store says "target busy"... <Guest141>no worry, you sort of answered my question <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>interesting. Will need to do more reading <unmatched-paren>But it seems like both / and /gnu/store are somehow on the same partiton <Guest141>Yeah, I see that. would make sense if btrfs, but it's ext4... <Cairn>Hey. I'm building up the courage to send my first patches. Does Guix use that "signoff" feature in git send-email? <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 <unmatched-paren>A commit to the repo will have author: <person who sent the commit> and signed-off-by: <person who pushed the commit> <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? <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` <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> --to=guix-patches@gnu.org` <unmatched-paren>and then `git send-email outgoing/*.patch --to=<bug-number>@debbugs.gnu.org` <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 --to=guix-patches@gnu.org` <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 <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) <Cairn>Yeah, I'm doing one commit per package I add/update <rhumbs>unmatched-paren `guix import crate -r` fetches some other crates, but not byteorder. I'll try to do it manually <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 <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? <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? <Cairn>Is that * line which reiterates the update manually written? <rhumbs>success! thank you for your help ummatched-paren ! <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>Hmm, actually, is environment-variables supposed to be able to take a file-like? <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> ("_JAVA_AWT_WM_NONREPARENTING" . #t))) <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 paste.debian.net). It worked ─ reconfiguration is under way right now! <unmatched-paren>How can I tell Emacs to load newly installed packages without restarting it? <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 <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? <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? <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>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. <Cairn>Whew. I committed all my changes to a branch. <Cairn>Now the scary part is git send-email <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 lists.sr.ht, but sadly debbugs isn't too clever <Cairn>I've got a cover letter written up. <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>$ git send-email outgoing/0000-<cover-letter-name> --to=guix-patches@gnu.org <jab>cassio: I'm a doom emacs guy. :) <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. <Cairn>Alright. Let me follow these steps then. I'll be back once I've sent my cover letter. <cassio>unmatched-paren: will do, thanks <unmatched-paren>$ git send-email -a --cover-letter -<num-commits> --to=foo-bar@example.com <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 =) *Cairn dances while waiting <unmatched-paren>It might take a little longer to show up on issues.guix.gnu.org though. <Cairn>unmatched-paren: Reponses have been slow for me in the past. Not sure why. <unmatched-paren>jab: git-send-email.io is nice, but doesn't warn you about the issues with debbugs (since it's a general guide) <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... <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>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. <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 jmp.chat. <jab>actually the jmp.chat guys, told me that they have a goal to package all of their dependencies in guix! <jab>Cairn: it's really cool. :) <jab>pkill9: paid? or paying? <pkill9>idk if there is even any benefits <pkill9>but oh well, i like it so i support it with my wallet <jab>pkill9: God bless your tender soul! haha <shcv[m]>jab: not to go too far off topic, but what do you use jmp.chat for? <pkill9>unmatched-paren: yeah i think that is yeh <jab>shcv[m]: I have a pinephone. I have two phone numbers that cost me a total of $13 per month. I use the jmp.chat 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. <jab>I actually use my laptop with my jmp.chat number. I have not figured out how to make calls via jmp.chat on my pinephone... <unmatched-paren>nice that the community can maintain quasi-official things like that <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 --to=guix-patches@gnu.org` <Cairn>And then I watched the output from my smtp and it said sent <Cairn>And then I checked my online web host and it says it's sent <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>unmatched-paren: Questions noted. *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? ***rgherdt_ is now known as rgherdt
<jab>nckx: how often does it get DDos-ed? <jab>grobx[m]: that warning you can safely disregard. <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 <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