Hello Guix,
Cuirass has stopped processing (old) jobs for aarch64 and x86_64. After
digging through the database it's because (db-get-pending-build ...)
returns a build that is missing from the Jobs table:
WITH pending_dependencies AS
(SELECT Builds.id, count(dep.id) as deps FROM Builds
Hello,
Maxim Cournoyer writes:
> Hello,
>
> This issue was triggered by having make-uboot-package uses #:target [0],
> but it already exists on current master. I've spent some time narrowing
> down the issue, and it is caused by the package returned by
> cross-kernel-headers in (gnu packages
Hi Ludo’,
On Sat, Jan 07, 2023 at 12:03 AM, Ludovic Courtès wrote:
> To be safe, you need to account for (getenv "PATH") returning #f, and
> not add a trailing colon in that case.
>
Ah, right. I think this would only happen if somehow unsetting PATH and
preserving it? As 'guix shell' already
Hello,
Ludovic Courtès writes:
> Hi,
>
> Pierre Langlois skribis:
>
>> I'm not sure I follow, I'd suggest to revert the revert and then apply a
>> fix in the same commit, that way it can easily be reverted again if it's
>> problematic, that's probably what you meant already?
>
> Sounds good to
Hello,
This issue was triggered by having make-uboot-package uses #:target [0],
but it already exists on current master. I've spent some time narrowing
down the issue, and it is caused by the package returned by
cross-kernel-headers in (gnu packages cross-base) being produced with a
bogus
Hi,
On ven., 13 janv. 2023 at 14:48, Ludovic Courtès
wrote:
> Nothing, because the ‘guix’ channel always comes first in the module
> search path (see ‘%package-module-path’ in (gnu packages)). Good.
>
> Now same scenario, but with references to another channel, for example
> (@ (past packages
My system administrator let me know that the terminal I was presented with was
sandboxed by RStudio Server (not running on Guix) and that this was responsible
for causing the error.
I was able to run the hello command from an unsandboxed shell. I was also able
to pull the latest version of
Hi Pierre,
Pierre Langlois writes:
> Hi Guix!
>
> I've been getting errors while running `guix pull' on an aarch64 system,
> during the final guix-package-cache step:
>
> (repl-version 0 1 1)
> Generating package cache for
> '/gnu/store/m8in1imi93snq711d7568dj9hlrx4diz-profile'...
>
>
In the light of the “dependency confusion” attack on PyTorch¹, one might
wonder how such a thing could affect Guix. The threat model is quite
different though because the ‘guix’ channel is peer-reviewed and curated
whereas PyPI isn’t.
Yet, one way to “translate” the attack to Guix is by looking
