bug#54495: unexpected download after gc

2023-10-31 Thread David Elsing
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)

bug#66866: aarch64 system cross compilation + pinebook pro image broken?

2024-02-11 Thread David Elsing
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

bug#69922: arcan-sdl does not build

2024-03-20 Thread David Elsing
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

bug#66866: aarch64 system cross compilation + pinebook pro image broken?

2024-04-10 Thread David Elsing
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

bug#66866: Grafting breaks cross-compilation

2024-05-12 Thread David Elsing
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

bug#54495: unexpected download after gc

2025-01-07 Thread David Elsing
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&#

bug#75879: [bug#70895] [PATCH] grafts: Only compute necessary graft derivations.

2025-01-31 Thread David Elsing
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

bug#75879: with-parameters does not work generally for packages

2025-01-26 Thread David Elsing
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

bug#76110: Broken i686 package on x86_64 since commit 28e4018e59

2025-02-08 Thread David Elsing
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

bug#75879: with-parameters does not work generally for packages

2025-02-25 Thread David Elsing
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

bug#75879: with-parameters does not work generally for packages

2025-02-17 Thread David Elsing
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

bug#76110: Broken i686 package on x86_64 since commit 28e4018e59

2025-03-02 Thread David Elsing
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