-
Notifications
You must be signed in to change notification settings - Fork 440
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some variables aren't properly set #4704
Comments
Thank you for reporting us your feedback! The internal ticket has been created: https://warthogs.atlassian.net/browse/CRAFT-2657.
|
I think this has the same root cause as #4702, so I would guess that the full fix for one would fix both. However I'm not going to close this as a duplicate and update the other bug for it because I'm only about 80% sure 😄 |
If I were a gambling man I would bet that the problem is that we aren't doing the equivalent of this in core24 projects |
extract the method Tiago mentions and call it also from Application._set_global_environment (https://github.com/canonical/craft-application/blob/1508796257c305a0b55e1af92056f82d2806f994/craft_application/application.py#L649 , requires calling parent) |
Fixed via #4757.
|
Bug Description
When building a core24 snap for a different architecture, the
BUILD_FOR
variables are set to the host architecture instead of the target.This might be similar to #4702
To Reproduce
Install snapcraft from
latest/edge
(tested with revision 11178)snapcraft
,snapcraft --build-for riscv64
, andsnapcraft --build-for=riscv64
all fail to set the correct architecture.Curiously,
snapcraft --build-for amd64
returns no errors but also doesn't do anything (no-op with no message?) but that may be unrelated.Environment
Snapcraft on a 23.10 host building with
--use-lxd
.snapcraft.yaml
Relevant log output
Additional context
Also of note:
SNAPCRAFT_PROJECT_{NAME,VERSION}
are invalid variables (though theirCRAFT_
counterparts are valid), which means the documentation is incorrect.SNAPCRAFT_PROJECT_GRADE
andCRAFT_PROJECT_GRADE
are never replaced and both raise an unbound variable error, but I think these things are more related to #4702 than this bug.The text was updated successfully, but these errors were encountered: