<drakonis>nixos defaults to using resolved and networkd so that's why
<jwoe324>actually according to my tests i think nix needs nscd too it's just not documented
<excalamus>gabr000, you should be able to just paste your snippet and press send. The URL will update with some numbers. It's the new URL you will want to share.
<gabr000>now i cant send the file because of spam and neither find the url where it is stored. xD
<psyklax>Is here some good documentation somewhere just for being a user of Guix? I've got some basic questions, like where am I supposed to put dotfiles, what's the correct way to source a .profile?
<excalamus>psyklax, in my experience, no, beyond what's in the manual. I've found it best to try things out and ask when it doesn't go right. I also try to document and publish what I do so that others can (hopefully) benefit.
<psyklax>How do you set it up to automatically source .guix-profile/etc/profile ?
<apteryx>lfam: perhaps ./bootstrap would have fixed it
*apteryx is getting more confident with core-updates-frozen-batched-changes, although it'd be nice if the CI assisted :-). not sure why it keeps failing to evaluate the branch. 'make as-derivation' passes locally
***LispyLights is now known as Aurora_v_kosmose
<podiki[m]>CI would be helpful, then someone can switch to it without rebuilding everything locally ;-)
<podiki[m]>after that branch is built and merged, any major blockers left on core-updates-frozen? or is it just fixing more individual packages to have better coverage before merging to master?
<apteryx>I know mothacehe was working fixing the failing system tests
<apteryx>after we've fixed the tests and are confident the branch is not far from master in terms of coverage, I guess the plan will be to merge to master, and then branch off to an RC branch soonish.
<apteryx>then polish things and prep the release material
<lfam>apteryx: I actually can't build from a fresh checkout
<Guest26>and others just said its not easy to do it lol
<nckx>That's certainly true. Despite your ‘just’ above, it's not actually the easy way or even well-supported on Guix, I'm afraid (as you found out). If those with experience can't help you I certainly can't.
<rekado>FWIW I’m getting the same error as lfam when building the master branch.
<apapsch>Though the IP parameter is a single address. This makes the procedure not usable for dual IPv4 and IPv6 configuration on a single interface, no?
<excalamus>I built a Plover plugin as a package. Part of that process was needing to update the definition for Plover itself to include (native-search-paths (package-native-search-paths python)). Without that, the plug would not be recognized (plugins need to be in site-packages). The definition for that and all the work surrounding it is here: http://excalamus.com/guix-case-study-plover-python-dictionary.html#org6114dbc Now, I'm trying it update
<excalamus>the Plover definition to a different version and to fix problems like no icons. I've started over with a new definition: https://paste.debian.net/1215847/ The new definition builds and I've installed it. The strange thing is that it recognizes plugins! This is not what I expected since the definition doesn't have native-search-paths.
<excalamus>does package-native-search-paths change something globally? Or I guess it wasn't actually needed?
<civodul>apapsch: hi! yes, static-networking-service is not very capable ATM
<apapsch>static networking seems useful against dhcp, as the latter periodically resets /etc/resolv.conf, overwriting custom config after starting dnsmasq
<vivien>Sometimes people complain about guix not pulling from "dumb" git HTTP servers, I’ve discovered that the solution is to simply keep a mirror of your dumb channels on disk, and have a cron job synchronize them with the regular git program.
<excalamus>jpoiret, I see you're correct. When I reinstall the current Guix Plover, which doesn't have the python search-path in it, the plugin is still recognized.
<rekado>on core-updates-frozen I get “guix build: error: gcry_md_hash_buffer: Function not implemented”
<rekado>just trying to run ’./pre-inst-env guix build salmon’
<jpoiret>excalamus: does that clear up how search-paths work?
<jpoiret>tbh they're not the easiest thing to understand in guix
<euandreh>vivien: the problem with that is that you can't have a channels.scm file that fully declares the desired channels
<excalamus>I mean it must have been something else that caused it to not be recognized. Since I reinstalled Plover from Guix, it seems to work, so yeah, dunno
<zacque>jpoiret, euandreh: Thanks, it works after commenting that line out. But I wonder why the package definition (see "guix edit scdoc") doesn't need a patch to remove that line? Asking since I'm learning to write its package definition
<euandreh>vivien: instead of "guix time-machine -C channels.scm -- environment -m manifest.scm -- cmd", having a "git -C ~/path/to/channel pull && guix environment -m manifest.scm"? Hmm, I didn't think of adding to the channels.scm the path of the local disk
<vivien>It’s more git fetch origin +refs/heads/*:refs/heads/* --prune
<nckx>euandreh: Your cron job/wrapper script could parse/sniff channels.scm to get the desired commit, but I feel like ‘solution’ is a tongue-in-cheek word anyway.
<vivien>But that’s done in a cron job, so you don’t have to run it yourself :)
<euandreh>zacque: that is weird, I thought the package was new, it indeed doesn't do that
<euandreh>vivien, nckx: yeah, I have a bit of knee-jerk reaction with this topic, because of Git itself, and how it doesn't provide any C API, so libgit re-implements it but chose not to do so for the dump http protocol.
<jpoiret>excalamus: when you build a profile, you get a union of all installed packages in the profile, with the search paths set to $GUIX_PROFILE/thesearchpathspec, so as long as you installed the plugin, it's gonna be visible to python
<euandreh>IMHO, the "Dumb HTTP" is better than both the "Smart HTTP" and "Git protocol". That is because there is nothing on the protocol itself that is about Git: the client just requests object by object, and the server responds. The server doesn't even need to know that it is a Git repository, those are all just static files.
<singpolyma>But why would we use any of those protocols at all when we have the ssh transport?
<euandreh>I acknowledge the need for some optimizations, like pulling big repositories or pushing changes, but I'd rather have those addressed someway else instead of having a new agreement on how to exchange things
<excalamus>jpoiret, okay. So, my best guess as for why things didn't work before but do now is that my profile was rebuilt in-between.
<euandreh>singpolyma: HTTP protocol is more common for public repos
<euandreh>singpolyma: but why adding a TLS layer is a hack?
<vivien>Git is often used in a way that each participant has a full copy, slightly modified. Publishing a git repository is in fact just publishing your version. So, there is a natural distinction between you and other people. Only you control (write) the repository, and the others just fetch. So, it’s natural to have 2 different access protocols: one for you (SSH), and one for everyone else (dumb HTTP). Since others don’t need to push to y
<vivien>our published copy, authentication by HTTP is not necessary.
<euandreh>I mean, you could compose a TLS program with an HTTP server, and the server wouldn't even know about TLS.
<vivien>I understand that different people have different uses of git, and I know that’s the case for guix, for instance, where a lot of different people have write access.
<shtumf[m]>I have 2 ssd, one has Manjaro GNU Linux installed on it and grub on it, I want to install GuixSD on the second disk, and probably this means that grub will also be installed on this second disk, after installation of GuixSD is done, what happens ? Does the GuixSD grub overwrite the fist disk Manjaro grub or will grubs be on each disk separatate, what do you suggest ? MAybe the question is realy does GuixSD when it install grub on ssd2, does
<shtumf[m]>it overwrite also the grub of Manjaro GNU Linux on ssd1 ?
<shtumf[m]>I suspect that all I have to do is manualy add the entry to borthgrubs for both ssd disks
<shtumf[m]>could it be done also this way that there is just one grub and I add in this grub for both ssd disks
<vivien>singpolyma, I like the distinction between what is public and what is private in your repository. That way, you can commit more carelessly because you’ll be able to rebase your work before pushing.
<roptat>shtumf[m], you can choose where grub is installed by guix, that's the targets field in the bootloader specification, in your os specification
<roptat>also, it's called "Guix System", not GuixSD anymore ;)
<civodul>IIRC, you mentioned that data.guix would miss substitute info from ci.guix because it wouldn't retry fetching narinfos, is that right?
<civodul>and because ci.guix doesn't send notifications
<attila_lendvai>civodul, i replied to the git-auth issue. i'll be more-or-less around in the next hour or two if you want a more interactive feedback loop. but i'll be around in the upcoming days, too.
<rekado>“festival” also fails to build. It’s the usual linker error, so should be easy to fix.
<rekado>any ideas what this might mean? “guix build: warning: failed to load '(gnu packages browser-extensions)': Function not implemented”
<rekado>and: “guix build: error: gcry_md_hash_buffer: Function not implemented”
<rekado>that’s what I get trying to build a package on a checkout of core-updates-frozen.
*attila_lendvai has just noticed that one of the commit messages is nonsense (using dynamic-wind)
<old>any recommendation for an alternative to xdg-open? Hopefully one that can be configured via Scheme?
<sailorCa`>Hi, fix me if I'm wrong. I'm going to define a go package. When I do a `guix build` it sapwns a container. The container by default has no network access. That's why on a check phase (that requires some network resources) I've got a problem.
<nckx>Provide all test requirements as native-inputs? I don't know if that's feasible; I also don't know enough about Go to know if it well then stop trying to invoke ‘go build’ and/or calling out to the network.
<podiki[m]>it would be nice to have some after install hooks or reminders of things to do manually after installing some packages
<robin>seems like a possible candidate for an install hook
<raiguy>libvirt can't find network "default". i had to copy it from my system profile to /etc/. annoying.
<robin>cehteh, that sort of exists, as the --without-tests package transformation option. but then it will be a different store item than if built without the option, so probably not useful for most things in practice (installing applications with slow test suites, maybe?)
<lilyp>hmm, you could try running a substitute server that builds --without-tests variants
<lilyp>though where to actually cut off tests is probably an issue
<jab>jpoiret: ok. I suppose that your idea has merit...and it would probably help the next hacker after me understand what is going on....
<jpoiret>in any case you're going to call `opensmtpd-table-type`, so it doesn't hurt readability
<jab>jpoiret: what do you think about my second use case? ensuring fieldname's are mutually exclusively used?
<jab>that's on (local-delivery opensmtpd-action-local-delivery
<jab>Essentially, I want (service opensmtpd-service) to use work for local delivery...so I am defining the default value of local-delivery.
<jab>But if someone says (service opensmtpd-service-type (opensmtpd-configuration (relay (opensmtpd-relay-configuration (host "smtp://other-host.com"))))), then the local-delivery default value will be #f and NOT be used.
<jpoiret>i guess it works, but you could've also had a single field that would discriminate based on the type of its value, eg if it is an `opensmtpd-relay-configuration` or an `opensmtpd-local-delivery-configuration`
<jpoiret>or just document that both modes are exclusive and let the user be responsible with its uses lol
<ajarara>If I have a patch dependent on another patch, should I lump the two patches in the same debbugs thread? Should I wait until merge/feedback of the dependency?
<ajarara>They are very different packages (libfido2 -> libcbor) so no motif between them. Just thinking about what eases maintainer lives.
<jab>jpoiret: oh...that's a good idea too. thanks for that suggestion!
<char>Is there a way to handle circular dependencies. It is for a testing library, so testing library depends on the library it is tesing. I don't really care about the testing library; I'm just trying to package the library being tested.