<g_bor>I've set a few patches that might go individually to core-updates, I think this is due only in the next update cycle. Once those are pushed I will send a patch series solving the hamcrest-core issue.
<g_bor>I have a questin, though. If we have a package, and we also have a bootstrap version of it, then is there any policy how to use inherit in this case?
<g_bor>Should the two definitions be independent? If we intend to separate language bootsrap, then that might be a good idea... However inheriting is less code... I don't know...
<g_bor>And if I do inherit, should I inherit the default from the bootsrap version?
<fis>Another not related question. I have tried to package some stuffs not already in the repo yet (sent to patches). I got curious about the original design choice of guix. Unlike nix or any other managers I know, packages recipes in guix are coupled with guix itself(stored in one git repo). Is there any reason to do that?
<str1ngs>dvn: unfortunately I live in NA, but I'm interested in guix and gnunet integration
<lfam>sneek later tell fis: By keeping the package definitions and the rest of the Guix code in the same repo, we avoid having to maintain an API between them, which allows us to work more quickly than otherwise.
<lfam>sneek later tell fis: You might compare it to how Linux keeps its drivers in the same repo as the kernel itself
<amz3>rekado: indeed, running 'guix build -c 1 -f guix.scm' makes it work
<str1ngs>dvn: do you know how to publish a directory then recursively download? I can share, but when I download using a hash all I get is a directory file. I can't find any documentation on how to recursively download a directory
<lfam>Hmm, seeing several of these on core-updates: error: ‘uintptr_t’ undeclared (first use in this function)
<ArneBab_xo>Hi, ArneBab here, only for a short note: I had problems with guix pull which disappeared when I explicitly ran guix package -i guix. If that is a general thing, it could be useful to mention in the docs to install guix as first thing after guix is working.
<ArneBab_xo>(I’m currently mostly cut off from communication)
<lfam>ArneBab_xo: If you have time, sending details about the problems to the mailing list would be helpful
<lfam>In general, it shouldn't be necessary to install the guix package on foreign distros. Instead, unprivileged users should be able to use the package symlinked from root's profile to /usr/local/bin/guix
<ArneBab_xo>I did not yet clear up whether I’m allowed to send to the ML from work.
<ArneBab_xo>(I started a month ago and am busy learning the ropes)
<ArneBab_xo>lfam: is it possible that the guix in roots profile can get too old to work after guix pull?
<ArneBab_xo>(I did not touch the root profile at all after the initial installation)
<lfam>Yes, but it depends on the details of the problems you experienced
<ArneBab_xo>I’ll see whether I can get get the tracebacks to you
<ArneBab_xo>and whether I can reproduce it by removing guix from the user profile
<ArneBab_xo>besides: it’s really nice to have guix at work - thank you for your great work on it!
<str1ngs>ArneBab_xo: this is a possibility where root profile gets to old. but it could be resolved by guix package -i guix as root. maybe that is what you meant earlier?
<ArneBab_xo>I did guix package -i guix as unpriviledged user
<lfam>"All three attack variants can allow a process with normal user privileges to perform unauthorized reads of memory data, which may contain sensitive information such as passwords, cryptographic key material, etc."
<lfam>It sounds like game over for protected kernel memory