msdobrescu
commented
2 years ago So, why is it trying to use the layer (from runtime deps) instead of the layerbase (from the build deps), for pandoc package?
Open msdobrescu opened 2 years ago
msdobrescu
commented
2 years ago So, why is it trying to use the layer (from runtime deps) instead of the layerbase (from the build deps), for pandoc package?
msdobrescu
commented
2 years ago Checked against Luet 0.32.1-gfea872aba055c5fa700c4ca3330cdc08e086ba42 2022-05-29, it's still an issue.
msdobrescu
commented
2 years ago Checked against Luet 0.32.2-gbac9bac25f6aa99507e42d0b0ec56b35363b7c62 2022-06-06, it's still an issue.
msdobrescu
commented
2 years ago Tried once more by using anchors like:
- &layers-ghc
category: "layers"
name: "ghc"
version: ">=0"
- &layerbase-ghc
category: "layerbase"
name: "ghc"
version: ">=0"
- &layers-haskell
category: "layers"
name: "haskell"
version: ">=0"
- &layerbase-haskell
category: "layers"
name: "haskell"
version: ">=0"Fails the same.
msdobrescu
commented
2 years ago A local build debug log.
It looks like it needs ghc layer as dependency of haskell layerbase.
mudler
commented
2 years ago mmm I don't see the layer/ghc under packages? https://github.com/mocaccinoOS/community-repository/blob/main/packages/apps/collection.yaml I see it in the anchors, but not sure if it gets built at all?
msdobrescu
commented
2 years ago Managed to skip this error when dropping subpackages usage.
Using subpackages seems to not work in this case, although not clear why, as layers were defined as subpackages and not the layer bases which are used to build. An enhancement to treat subpackages as the main packages would be great, if possible.
I think the explanation for this problems is this: haskell was "hard-linked" to ghc by anchors to the definition directly, so it has found it regardless a typo in its category, but pandoc is in another collection, so was "soft-linked" to them and failed building Although I have corrected ghc and haskell definitions, finding the typo when changed haskell definition to be "soft-linked" to ghc and failed, rebuilt them and worked, I've forgotten to increase pandoc's version. I think this was the reason to fail again and again. Is it possible luet was reusing something from the old build due to the same pandoc version, even though it failed at the time building that version? Increasing pandoc's version seems to change the build process. Makes sense?
Luet version:
0.32.0-g2aa4c8a42ed13682b4820f3ca5e6d2388a5e2c24 2022-05-03
CPU architecture, OS, and Version:
github's
Describe the bug
I have hit am issue :
ERROR Error: while resolving join images: could not generate image hash: Error while generating compilespec for ghc: Candidate not found: No key found for: ghc-layers-8.10.4-r1+1In short, built a ghc layer split in two, one "standard" layer, one "layerbase" (the layer + portage db), then, based on it, similarly a haskell set (layer+layerbase) and now I try to build a package based on haskell. This fails and I wonder why. Can you help clarifuying this when possible?
To Reproduce
Use the following package def
From here:
From here:
The package that fails:
Expected behavior
Build succeeds.
Logs
https://github.com/mocaccinoOS/community-repository/runs/6484389795?check_suite_focus=true#step:9:1794
Additional context