<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>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>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
<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>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>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
<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
<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 email@example.com, and that's already scary, we'd best not add more things).
<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
<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>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.
<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.
<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^^
<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.
<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`?
<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>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>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?
<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>(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)
<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>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