Hello,
AFAICT, there is no way to determine which ungrafted package a grafted
package comes from without the derivation of the grafted package (where
the ungrafted package is referenced). Therefore, I think adding a
reference to the ungrafted package in the package itself (your second
suggestion)
Hello,
Mathieu Othacehe writes:
> I could narrow it down somehow.
Starting from alsa-lib, I narrowed it down further. I found that the
problem is actually when an input of the package uses copy-build-system.
In the following example, the cross-compilation (with
--target=x86_64-linux-gnu) for t
Hello,
> While reviewing https://issues.guix.gnu.org/69866, I noticed that
> arcan-sdl is failing. I'm recording some notes from looking at the CI
> pages here.
I meant to reply to this issue, but accidentally opened a new issue with
the patch fixing it: https://issues.guix.gnu.org/69923
Should
Hi dan,
sorry for the late reply. I didn't yet find the reason why different
bootstrap packages are built for the cross build when grafts are
applied. This seems possibly like another bug to me, as the package
inputs which use copy-build-system do not contain store references and
it does not happe
Hello,
I think I finally understand why the problem only occurs with grafts if
a dependency uses copy-build-system. It is actually somewhat
complicated.
When a package is lowered into a derivation by 'package->derivation' in
guix/packages.scm, a list of potentially applicable grafts is created by
Hello,
David Elsing writes:
> Presently, it is inconvenient to globally run guix gc at all for me, as
> many (dependent) packages are deleted and substituted again when
> rebuilding several profiles built with grafts.
In the meantime, I learned about the '--gc-keep-outputs&#
Hello,
Ludovic Courtès writes:
> Uh, looks like this is a real bug. I’m surprised because we do have
> tests for that in ‘tests/gexp.scm’ (and it’s actually used in a few
> important places), but maybe they’re not exercising the right thing.
Yes indeed, 'with-parameters' is tested for %current
Hello,
I noticed that 'with-parameters' from (guix gexp) does not work with
Guile parameters used in package definitions. They are still set
in 'lower-object', but not anymore when the monadic procedure returned
by 'lower-object' is evaluated.
Attached is an example for a package wrapped by 'with
Hi,
Denis 'GNUtoo' Carikli writes:
> And the process gave the commit 28e4018e59d30efb3d52aa950ce2261f11b69b33
> ("grafts: Allow file-like objects in the ‘replacement’ field of
> .").
>
> However I didn't look into how to repair the behavior above as I'm not
> familiar at all with the code that t
Hi Ludo',
Ludovic Courtès writes:
> Something just came to mind: the object cache. The cache is keyed by
> object + system + target + grafts?; if there’s anything that influences
> what the object lowers to, changes are the object->derivation mapping is
> already cached and that other thing wil
Hello,
Ludovic Courtès writes:
> David, would you be willing/able to send it as a proper patch to
> guix-patches, ideally with a test?
The patch is here: https://issues.guix.gnu.org/76694
I had to adjust other tests as well, because the replacement can now
only be compared by lowering it to a d
Hi Ludo',
Ludovic Courtès writes:
> Problem is that the key must remain “small” so that computing its hash
> is fast. It cannot grow further than its current size, I’m afraid.
What if the hash is calculated in `compile-parameterized' instead (as
that is the only supported way to set the parame
Hello,
Ludovic Courtès writes:
> I don’t actually use podman and Docker but I think it would be nice if
> the unprivileged guix-daemon would work out of the box in these
> environments, particularly in CI environments like GitLab-CI where
> passing ‘--security-opt=seccomp=unconfined’ is not an o
Hello,
Ludovic Courtès writes:
> When running guix-daemon unprivileged in Docker (or, similarly, in a
> ‘guix pack -R’ relocatable pack), it fails to spawn the build process:
> [...]
> The clone(2) man page lists two reasons for getting EPERM with
> CLONE_NEWUSER:
I'm not sure about `guix pack
Hi,
Ludovic Courtès writes:
> But it’s unsatisfactory: I would hope the unprivileged daemon would
> allow us to address that shortcoming.
Yes it does, as long as the needed syscalls are not restricted. I'm not
sure when this will change with Docker [1].
>> I don't think the isolated build envi
Hi,
Ludovic Courtès writes:
> So hmm, it looks like in practice we’re left with no choice but to keep
> using ‘--disable-chroot’ in Docker?
Without unprivileged user namespaces being allowed, the situation hasn't
changed I think.
> Do you happen to know what people running Docker-in-Docker (or
16 matches
Mail list logo
