<gnewb>I am trying to write a package definition but guix lint says that all source <gnewb>URIs are unreachable even though the URI works when I try it with wget. <lfam>gnewb: What about `guix build`? Can you build the package, including downloading the source? <gnewb>Yes guix build works. I just checked again after deleting the source from the store with guix gc. <lfam>Strange! Well, if that works, I'd report the lint error as a bug <gnewb>lfam: I will report it. Thanks. <Digit>"interesting. https://criu.org/Main_Page" - me, a few hours ago. n now i ponder its wonders in contexts of guix, where edge uses might become more viable/reliable. <Digit>idk. just thought i'd mention it, incase some guix geeks pick up on something interesting n tangible, that i only vaguely imagine. ***pksadiq__ is now known as pksadiq
<db48x`>do we have to subscribe to the mailing lists in order to email them? ***db48x` is now known as db48x
<efraim>The first email is often delayed unless you've subscribed <rekado_>Digit: I packaged criu because I was fascinated by the idea of per-process hibernation or “targetted swapping” <rekado_>we’d need to rebuild the kernel with a certain option to make it work, though. <shiranaihito>the website says Guix(SD) is not "production-ready" .. is that actually the case? :) <db48x>shiranaihito: I'm not an expert, but it's incomplete, there are bugs (known and unknown), the packages you need might not be available, and people are hedging their bets <db48x>you could probably use it in production if you wanted, as long as you're willing to step in and write the code that fixes the problems you encounter <shiranaihito>db48x alrighty :). well, how would you say it's incomplete? <shiranaihito>db48x mm.. weeell, i'm certainly interested in using Guix(SD) - i think it holds great promise for the future <shiranaihito>but i've never written C/C++ and i don't know "low level" Unix stuff, so .. i'm not sure i could "fix it" myself <db48x>ah, you're in luck; it's written in Scheme, not C++ :) <db48x>I'll give you an example of something that's incomplete <db48x>to configure your system you'll write some scheme that sets things up <db48x>then use 'guix reconfigure' to apply it to the system <shiranaihito>i wish Guix had Clojure's syntax .. at least roughly similar, square brackets in lets and so on :) <db48x>but guix reconfigure doesn't at the moment know when to restart the services <shiranaihito>but now we're not talking about fixing bugs, at least :) <db48x>if you were using it in production, that would be an annoying thing you had to remember to do manually <shiranaihito>db48x yeah, but i might use something from HashiCorp to manage stuff <efraim>icu4c FTBFS on aarch64 on core-updates <brendyn>synergy fails to build at the check phase for me <efraim>upgrading icu4c to 60.1 fixes the FTBFS <xelxebar>I just installed vim and it's warning that I need to relink libpng and libfreetype with libpthread <xelxebar>Has anyone encountered this before? It seems like my glibc is screwy? <xelxebar>In that case a guix pull && guix package -u seemed to fix things, but that's not working for me. <xelxebar>Anyway, any debugging assistance would be much appreciated. <bavier>it seems weird that I'd need a different glibc for building a profile <lfam>bavier: I'm not sure exactly what you're describing, but glibc is currently grafted, so perhaps you hadn't updated since we added that graft <bavier>lfam: updated with 'git pull', built a bunch of packages, then a 'guix environment --container' causes a glibc to be built <bavier>I just assumed the glibc used for all the first packages would have been used for the profile hooks <lfam>I agree, the behavior is confusing. I'm not sure what happened <lfam>I just did `guix build glibc` and it downloaded /gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25 <lfam>I'd expect that I already had this in my store... <lfam>I'm having trouble figuring out which glibc package is referenced by installed packages <lfam>It's not (gnu packages base (glibc/linux)) <taohansen>i can see we have docker-compose but does this mean we also have docker itself? <bavier>finally found a solution to some packages' mpi tests hanging/timing-out on low-core-count machines <bavier>openmpi has to be told to oversubscribe and yield to other processes occasionally <ng0>Hi. I'm doing some emacs package updates. We didn't come up with some custom @'s for Texinfo, right? because the description of emacs-slime should've been linted... I'm fixing that aswell <ng0>Common Lisp. The features are centered around @{slime-mode}, an Emacs <- @{.....} is never valid <ng0>even when we had custom ones, @ on its own is garbage and doesn't work