| Message ID | SJ0PR18MB3898AC687557A2CD4FA0340995599@SJ0PR18MB3898.namprd18.prod.outlook.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [PATCHv2,1/1] package/rustc: add musl as an available Rust libc | expand |
Hello Nathaniel, On Wed, 5 May 2021 11:53:46 -0400 Nathaniel Husted <nathaniel.husted@outlook.com> wrote: > The current rustc package only supports gnu libc and hardcodes this > requirement. This patch adds musl to the available libc options for > Rust packages. Musl is now a Tier 2 supported environment for Rust. > Tier 2 means the platforms are "guaranteed to build" and official > binary releases are available. The changes in rustc.mk will also > support adding uclibc when that environment reaches Tier 2 support > but does not allow for uclibc currently as it is still a Tier 3 > supported environment. > > This patch includes corrections from the prior version submitted > in March, 2021. > > Signed-off-by: Nathaniel Husted <nathaniel.husted@outlook.com> Thanks a lot. Unfortunately, after a more careful review, this patch still has issues: (1) You're not updating package/rust-bin/rust-bin.hash for all those new target platforms, so the download will fail as hashes are not available. (2) Changing "depends on glibc" with "depends on glibc || musl" doesn't work as some architectures that are supported with glibc are not supported with musl. So I went on and wrote a more complete/complex solution, which I have submitted at: https://patchwork.ozlabs.org/project/buildroot/list/?series=244536 Best regards, Thomas
Hi Thomas, Apologies for missing the robust engineering solution there. As a follow-up question, how does the buildroot community generally handle .hash file updates? Should these always be done in a package patch set via multiple parts? Do you test the gpg keys and sha256sums "by hand" or is there a utility used when version update commits occur? I was looking through the contributor documentation to determine expectations with respect to patches and looked through the utilities folder to see if there were supporting tools but could not find a discussion. Cheers, Nathaniel
Nathaniel, All, On 2021-05-19 12:35 +0000, Nathaniel Husted spake thusly: > Apologies for missing the robust engineering solution there. It's not a problem! ;-) In fact, often it is only when actually reviewing and hacking on a patch, that a better solution appears. And then, it gets faster to just write the patch and send it for review, than explain it in human-words. > As a follow-up question, how does the buildroot community generally > handle .hash file updates? This is a manual step. What I do when I bump a version, is I modify it in the hash file but leave the old hash as-is, then I do the download, and the hash obviously does not match, but the new one is dsplayed, so I update the hash file with it, and verify it by redownloading. > Should these always be done in a package patch set via multiple parts? The update of the hash file must be done in the same patch that updates the version. > Do you test the gpg keys and sha256sums "by hand" or is there a > utility used when version update commits occur? There is no tooling in the Buildroot tree, no. Verifying signatures is done manually. In this case, I think Thomas, after downloading all the archives and their .asc, basically did: for i in *.asc; do gpg --verify ${i}; done But this case is exceptional; usually, there is only one file for which to check the hash and signature, not 16! :-) Also, I do not usually verify many signatures, since I have almost zero connection in the WoT, so verifying a sig does not bring much benefit. But if my download got compromised (maliciously or accidentally), the hash I added will be wrong for someone else, especially the autobuilders, and we can act on the issue. Of course, this does not work if the remote server was compromised, but in that case, checking the signatures without a good trust-chain in the WoT is useless too... > I was looking through the contributor documentation to determine > expectations with respect to patches and looked through the utilities > folder to see if there were supporting tools but could not find a > discussion. No, there is no tooling, and there is only the manual about hash files: https://buildroot.org/downloads/manual/manual.html#adding-packages-hash Thanks for your contribution! :-) Regards, Yann E. MORIN.
On 19/05/2021 17:01, Yann E. MORIN wrote: >> Do you test the gpg keys and sha256sums "by hand" or is there a >> utility used when version update commits occur? > There is no tooling in the Buildroot tree, no. Verifying signatures is > done manually. In this case, I think Thomas, after downloading all the > archives and their .asc, basically did: > for i in *.asc; do gpg --verify ${i}; done > > But this case is exceptional; usually, there is only one file for which > to check the hash and signature, not 16! :-) > > Also, I do not usually verify many signatures, since I have almost zero > connection in the WoT, so verifying a sig does not bring much benefit. I do some kind of TOFU because I store the signing key so next time I update the same package, the signature should match. Of course, I rarely update any package, certainly not twice, so the benefit is limited in my personal case :-) Regards, Arnout > But if my download got compromised (maliciously or accidentally), the > hash I added will be wrong for someone else, especially the autobuilders, > and we can act on the issue. > > Of course, this does not work if the remote server was compromised, but > in that case, checking the signatures without a good trust-chain in the > WoT is useless too... >
diff --git a/package/rustc/Config.in.host b/package/rustc/Config.in.host index 1df25ae326..4ab9086446 100644 --- a/package/rustc/Config.in.host +++ b/package/rustc/Config.in.host @@ -17,7 +17,7 @@ config BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS default y if (BR2_mips || BR2_mipsel) && !BR2_MIPS_CPU_MIPS32R6 default y if (BR2_mips64 || BR2_mips64el) && !BR2_MIPS_CPU_MIPS64R6 \ && BR2_MIPS_NABI64 - depends on BR2_TOOLCHAIN_USES_GLIBC + depends on BR2_TOOLCHAIN_USES_GLIBC || BR2_TOOLCHAIN_USES_MUSL depends on BR2_PACKAGE_HOST_RUSTC_ARCH_SUPPORTS config BR2_PACKAGE_HOST_RUSTC_ARCH diff --git a/package/rustc/rustc.mk b/package/rustc/rustc.mk index 35ffc36106..c5a42f0c1d 100644 --- a/package/rustc/rustc.mk +++ b/package/rustc/rustc.mk @@ -4,11 +4,13 @@ # ################################################################################ + + RUSTC_ARCH = $(call qstrip,$(BR2_PACKAGE_HOST_RUSTC_ARCH)) RUSTC_ABI = $(call qstrip,$(BR2_PACKAGE_HOST_RUSTC_ABI)) ifeq ($(BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS),y) -RUSTC_TARGET_NAME = $(RUSTC_ARCH)-unknown-linux-gnu$(RUSTC_ABI) +RUSTC_TARGET_NAME = $(RUSTC_ARCH)-unknown-linux-$(LIBC)$(RUSTC_ABI) endif ifeq ($(HOSTARCH),x86)
The current rustc package only supports gnu libc and hardcodes this requirement. This patch adds musl to the available libc options for Rust packages. Musl is now a Tier 2 supported environment for Rust. Tier 2 means the platforms are "guaranteed to build" and official binary releases are available. The changes in rustc.mk will also support adding uclibc when that environment reaches Tier 2 support but does not allow for uclibc currently as it is still a Tier 3 supported environment. This patch includes corrections from the prior version submitted in March, 2021. Signed-off-by: Nathaniel Husted <nathaniel.husted@outlook.com> --- package/rustc/Config.in.host | 2 +- package/rustc/rustc.mk | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-)