[OE-core] [PATCH] Revert "ipk: Decode byte data to string in manifest handling"

2023-05-05 Thread Andrew Jeffery 
cf9df9e8d89f ("ipk: Decode byte data to string in manifest handling")
did a bit of least-effort fix to a string vs byte sequence issue in the
manifest handling. The approach was chosen as it localised the fix,
rather than having to analyse further call sites.

However since then f2167ae80258 ("package_manager/ipk: do not pipe
stderr to stdout") was applied, reworking the output handling from the
subcommand. dummy_bytes() now returns a string, so stop trying to decode
it.

Fixes: f2167ae80258 ("package_manager/ipk: do not pipe stderr to stdout")
Cc: Curtis Meier 
Cc: Pam Eggler 
Signed-off-by: Andrew Jeffery 
---
 meta/lib/oe/package_manager/ipk/manifest.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/package_manager/ipk/manifest.py 
b/meta/lib/oe/package_manager/ipk/manifest.py
index 469e14c3c6b8..3549d7428d72 100644
--- a/meta/lib/oe/package_manager/ipk/manifest.py
+++ b/meta/lib/oe/package_manager/ipk/manifest.py
@@ -64,7 +64,7 @@ class PkgManifest(Manifest):
 if len(pkgs_to_install) == 0:
 return
 
-output = pm.dummy_install(pkgs_to_install).decode('utf-8')
+output = pm.dummy_install(pkgs_to_install)
 
 with open(self.full_manifest, 'w+') as manifest:
 pkg_re = re.compile('^Installing ([^ ]+) [^ ].*')
-- 
2.40.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180916): 
https://lists.openembedded.org/g/openembedded-core/message/180916
Mute This Topic: https://lists.openembedded.org/mt/98705163/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/2] ipk: Decode byte data to string in manifest handling

2022-03-02 Thread Andrew Jeffery 
```
File: 
'/home/andrew/src/openbmc/openbmc/meta/lib/oe/package_manager/ipk/manifest.py', 
lineno: 69, function: create_full
 0065:output = pm.dummy_install(pkgs_to_install)
 0066:
 0067:with open(self.full_manifest, 'w+') as manifest:
 0068:pkg_re = re.compile('^Installing ([^ ]+) [^ ].*')
 *** 0069:for line in set(output.split('\n')):
 0070:m = pkg_re.match(line)
 0071:if m:
 0072:manifest.write(m.group(1) + '\n')
 0073:
Exception: TypeError: a bytes-like object is required, not 'str'
```

Change-Id: Ifefb13bfa22c766d20ab9f73f7abe5163b3df86f
Signed-off-by: Andrew Jeffery 
---
 meta/lib/oe/package_manager/ipk/manifest.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/package_manager/ipk/manifest.py 
b/meta/lib/oe/package_manager/ipk/manifest.py
index 22669f97c082..ae451c5c70d3 100644
--- a/meta/lib/oe/package_manager/ipk/manifest.py
+++ b/meta/lib/oe/package_manager/ipk/manifest.py
@@ -62,7 +62,7 @@ class PkgManifest(Manifest):
 if len(pkgs_to_install) == 0:
 return
 
-output = pm.dummy_install(pkgs_to_install)
+output = pm.dummy_install(pkgs_to_install).decode('utf-8')
 
 with open(self.full_manifest, 'w+') as manifest:
 pkg_re = re.compile('^Installing ([^ ]+) [^ ].*')
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162609): 
https://lists.openembedded.org/g/openembedded-core/message/162609
Mute This Topic: https://lists.openembedded.org/mt/89500662/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/2] ipk: Import re in manifest module

2022-03-02 Thread Andrew Jeffery 
```
File: 
'/home/andrew/src/openbmc/openbmc/meta/lib/oe/package_manager/ipk/manifest.py', 
lineno: 67, function: create_full
 0063:
 0064:output = pm.dummy_install(pkgs_to_install)
 0065:
 0066:with open(self.full_manifest, 'w+') as manifest:
 *** 0067:pkg_re = re.compile('^Installing ([^ ]+) [^ ].*')
 0068:for line in set(output.split('\n')):
 0069:m = pkg_re.match(line)
 0070:if m:
 0071:manifest.write(m.group(1) + '\n')
Exception: NameError: name 're' is not defined
```

Change-Id: I769a2ab5e57c7b60598ea0390b576d707356db9d
Signed-off-by: Andrew Jeffery 
---
 meta/lib/oe/package_manager/ipk/manifest.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/lib/oe/package_manager/ipk/manifest.py 
b/meta/lib/oe/package_manager/ipk/manifest.py
index ee4b57bcb0f5..22669f97c082 100644
--- a/meta/lib/oe/package_manager/ipk/manifest.py
+++ b/meta/lib/oe/package_manager/ipk/manifest.py
@@ -3,6 +3,7 @@
 #
 
 from oe.manifest import Manifest
+import re
 
 class PkgManifest(Manifest):
 """
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162608): 
https://lists.openembedded.org/g/openembedded-core/message/162608
Mute This Topic: https://lists.openembedded.org/mt/89500661/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2 3/3] rust: Add snapshot checksums for powerpc64le

2022-02-28 Thread Andrew Jeffery 
Signed-off-by: Andrew Jeffery 
---
 meta/recipes-devtools/rust/rust-snapshot.inc | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-devtools/rust/rust-snapshot.inc 
b/meta/recipes-devtools/rust/rust-snapshot.inc
index 173648c889fb..d0c05aec7866 100644
--- a/meta/recipes-devtools/rust/rust-snapshot.inc
+++ b/meta/recipes-devtools/rust/rust-snapshot.inc
@@ -14,6 +14,10 @@ SRC_URI[rust-std-snapshot-aarch64.sha256sum] = 
"3618da916a0f92f241cf1d67d04bb578
 SRC_URI[rustc-snapshot-aarch64.sha256sum] = 
"f26811e48d03c56c125de03d389e1ae7c6df36990953c1670c6a5676bc12d4cb"
 SRC_URI[cargo-snapshot-aarch64.sha256sum] = 
"6d11cd94618d80cda273eeeae7285980445f61a49ebacc616777b482a41cbf3f"
 
+SRC_URI[rust-std-snapshot-powerpc64le.sha256sum] = 
"fc07eb3e9f3d227428cc5b53ca868e3de375bc198ce4dce7b87a9246e6fec81a"
+SRC_URI[rustc-snapshot-powerpc64le.sha256sum] = 
"f43cb99109c3438c77c7079cdce4673df3320e310158e0b4d949c1babc4300fc"
+SRC_URI[cargo-snapshot-powerpc64le.sha256sum] = 
"599cf1b5a8cdbf76d591621bc9222aefa60e2f5fd378ae71c4dcf4514c47122e"
+
 SRC_URI += " \
 
https://static.rust-lang.org/dist/${RUST_STD_SNAPSHOT}.tar.xz;name=rust-std-snapshot-${RUST_BUILD_ARCH};subdir=rust-snapshot-components
 \
 
https://static.rust-lang.org/dist/${RUSTC_SNAPSHOT}.tar.xz;name=rustc-snapshot-${RUST_BUILD_ARCH};subdir=rust-snapshot-components
 \
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162504): 
https://lists.openembedded.org/g/openembedded-core/message/162504
Mute This Topic: https://lists.openembedded.org/mt/89451435/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2 2/3] rust: Introduce RUST_BUILD_ARCH

2022-02-28 Thread Andrew Jeffery 
RUST_BUILD_ARCH contains the arch_to_rust_arch()-translated value of
BUILD_ARCH. This is necessary to acquire the correct snapshot artifacts
under Linux where `uname -m` reports "ppc64le" rather than
"powerpc64le".

Change-Id: I6aec23aced8e1c6f0bfc46fe52531b0c16bcf687
Signed-off-by: Andrew Jeffery 
---
 meta/classes/rust-common.bbclass |  4 
 meta/recipes-devtools/rust/rust-snapshot.inc | 12 ++--
 meta/recipes-devtools/rust/rust.inc  |  2 +-
 3 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/meta/classes/rust-common.bbclass b/meta/classes/rust-common.bbclass
index 8cfe864ca3fd..65ad677499cb 100644
--- a/meta/classes/rust-common.bbclass
+++ b/meta/classes/rust-common.bbclass
@@ -89,6 +89,10 @@ def rust_base_triple(d, thing):
 libc = bb.utils.contains('TUNE_FEATURES', 'callconvention-hard', 'hf', 
'', d)
 return arch + vendor + '-' + os + libc
 
+
+# In some cases uname and the toolchain differ on their idea of the arch name
+RUST_BUILD_ARCH = "${@oe.rust.arch_to_rust_arch(d.getVar('BUILD_ARCH'))}"
+
 # Naming explanation
 # Yocto
 # - BUILD_SYS - Yocto triple of the build environment
diff --git a/meta/recipes-devtools/rust/rust-snapshot.inc 
b/meta/recipes-devtools/rust/rust-snapshot.inc
index 74b558262f62..173648c889fb 100644
--- a/meta/recipes-devtools/rust/rust-snapshot.inc
+++ b/meta/recipes-devtools/rust/rust-snapshot.inc
@@ -15,11 +15,11 @@ SRC_URI[rustc-snapshot-aarch64.sha256sum] = 
"f26811e48d03c56c125de03d389e1ae7c6d
 SRC_URI[cargo-snapshot-aarch64.sha256sum] = 
"6d11cd94618d80cda273eeeae7285980445f61a49ebacc616777b482a41cbf3f"
 
 SRC_URI += " \
-
https://static.rust-lang.org/dist/${RUST_STD_SNAPSHOT}.tar.xz;name=rust-std-snapshot-${BUILD_ARCH};subdir=rust-snapshot-components
 \
-
https://static.rust-lang.org/dist/${RUSTC_SNAPSHOT}.tar.xz;name=rustc-snapshot-${BUILD_ARCH};subdir=rust-snapshot-components
 \
-
https://static.rust-lang.org/dist/${CARGO_SNAPSHOT}.tar.xz;name=cargo-snapshot-${BUILD_ARCH};subdir=rust-snapshot-components
 \
+
https://static.rust-lang.org/dist/${RUST_STD_SNAPSHOT}.tar.xz;name=rust-std-snapshot-${RUST_BUILD_ARCH};subdir=rust-snapshot-components
 \
+
https://static.rust-lang.org/dist/${RUSTC_SNAPSHOT}.tar.xz;name=rustc-snapshot-${RUST_BUILD_ARCH};subdir=rust-snapshot-components
 \
+
https://static.rust-lang.org/dist/${CARGO_SNAPSHOT}.tar.xz;name=cargo-snapshot-${RUST_BUILD_ARCH};subdir=rust-snapshot-components
 \
 "
 
-RUST_STD_SNAPSHOT = "rust-std-${RS_VERSION}-${BUILD_ARCH}-unknown-linux-gnu"
-RUSTC_SNAPSHOT = "rustc-${RS_VERSION}-${BUILD_ARCH}-unknown-linux-gnu"
-CARGO_SNAPSHOT = "cargo-${CARGO_VERSION}-${BUILD_ARCH}-unknown-linux-gnu"
+RUST_STD_SNAPSHOT = 
"rust-std-${RS_VERSION}-${RUST_BUILD_ARCH}-unknown-linux-gnu"
+RUSTC_SNAPSHOT = "rustc-${RS_VERSION}-${RUST_BUILD_ARCH}-unknown-linux-gnu"
+CARGO_SNAPSHOT = "cargo-${CARGO_VERSION}-${RUST_BUILD_ARCH}-unknown-linux-gnu"
diff --git a/meta/recipes-devtools/rust/rust.inc 
b/meta/recipes-devtools/rust/rust.inc
index 1d6f99afad31..f39228e3c08d 100644
--- a/meta/recipes-devtools/rust/rust.inc
+++ b/meta/recipes-devtools/rust/rust.inc
@@ -27,7 +27,7 @@ CARGO_DISABLE_BITBAKE_VENDORING = "1"
 
 # We can't use RUST_BUILD_SYS here because that may be "musl" if
 # TCLIBC="musl". Snapshots are always -unknown-linux-gnu
-SNAPSHOT_BUILD_SYS = "${BUILD_ARCH}-unknown-linux-gnu"
+SNAPSHOT_BUILD_SYS = "${RUST_BUILD_ARCH}-unknown-linux-gnu"
 setup_cargo_environment () {
 # The first step is to build bootstrap and some early stage tools,
 # these are build for the same target as the snapshot, e.g.
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162503): 
https://lists.openembedded.org/g/openembedded-core/message/162503
Mute This Topic: https://lists.openembedded.org/mt/89451432/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2 1/3] rust: Introduce arch_to_rust_arch()

2022-02-28 Thread Andrew Jeffery 
On modern Power systems `uname -m` yields 'ppc64le' while the toolchain
knows the architecture as 'powerpc64le'. Provide a mapping from one to
the other to integrate with the existing architecture configuration
flags.

arch_to_rust_arch() only exists to map the OE *_ARCH variables before
any further processing, unlike arch_to_rust_target_arch() which is
specific to the internal triple handling of rust.

On Linux ppc64le systems the changes give the following config:

```
$ cat ./tmp/work/ppc64le-linux/rust-native/1.58.0-r0/targets/ppc64le-linux.json
{
"llvm-target": "powerpc64le-unknown-linux-gnu",
"data-layout": "e-m:e-i64:64-n32:64-v256:256:256-v512:512:512",
"max-atomic-width": 64,
"target-pointer-width": "64",
"target-c-int-width": "64",
"target-endian": "little",
"arch": "powerpc64",
"os": "linux",
"env": "gnu",
"vendor": "unknown",
"target-family": "unix",
"linker": "gcc",
"cpu": "generic",
"dynamic-linking": true,
"executables": true,
"linker-is-gnu": true,
"linker-flavor": "gcc",
"has-rpath": true,
"has-elf-tls": true,
"position-independent-executables": true,
"panic-strategy": "unwind"
}
```

Change-Id: Ief0c01189185d7d4da31d307270bec4e1de674ca
Signed-off-by: Andrew Jeffery 
---
 meta/classes/base.bbclass  | 2 +-
 meta/classes/rust-common.bbclass   | 2 +-
 meta/lib/oe/rust.py| 5 +
 meta/recipes-devtools/rust/rust-common.inc | 8 +---
 4 files changed, 12 insertions(+), 5 deletions(-)
 create mode 100644 meta/lib/oe/rust.py

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 55f654d37d0c..27c1d6168d45 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -12,7 +12,7 @@ inherit logging
 
 OE_EXTRA_IMPORTS ?= ""
 
-OE_IMPORTS += "os sys time oe.path oe.utils oe.types oe.package 
oe.packagegroup oe.sstatesig oe.lsb oe.cachedpath oe.license oe.qa 
oe.reproducible ${OE_EXTRA_IMPORTS}"
+OE_IMPORTS += "os sys time oe.path oe.utils oe.types oe.package 
oe.packagegroup oe.sstatesig oe.lsb oe.cachedpath oe.license oe.qa 
oe.reproducible oe.rust ${OE_EXTRA_IMPORTS}"
 OE_IMPORTS[type] = "list"
 
 PACKAGECONFIG_CONFARGS ??= ""
diff --git a/meta/classes/rust-common.bbclass b/meta/classes/rust-common.bbclass
index 98d65970e8c0..8cfe864ca3fd 100644
--- a/meta/classes/rust-common.bbclass
+++ b/meta/classes/rust-common.bbclass
@@ -65,7 +65,7 @@ def rust_base_triple(d, thing):
 if thing == "TARGET" and target_is_armv7(d):
 arch = "armv7"
 else:
-arch = d.getVar('{}_ARCH'.format(thing))
+arch = oe.rust.arch_to_rust_arch(d.getVar('{}_ARCH'.format(thing)))
 
 # All the Yocto targets are Linux and are 'unknown'
 vendor = "-unknown"
diff --git a/meta/lib/oe/rust.py b/meta/lib/oe/rust.py
new file mode 100644
index ..ec70b348054d
--- /dev/null
+++ b/meta/lib/oe/rust.py
@@ -0,0 +1,5 @@
+# Handle mismatches between `uname -m`-style output and Rust's arch names
+def arch_to_rust_arch(arch):
+if arch == "ppc64le":
+return "powerpc64le"
+return arch
diff --git a/meta/recipes-devtools/rust/rust-common.inc 
b/meta/recipes-devtools/rust/rust-common.inc
index c9786376..310aecef226e 100644
--- a/meta/recipes-devtools/rust/rust-common.inc
+++ b/meta/recipes-devtools/rust/rust-common.inc
@@ -313,10 +313,12 @@ def rust_gen_target(d, thing, wd, features, cpu, arch, 
abi=""):
 sys = sys_for(d, thing)
 prefix = prefix_for(d, thing)
 
+rust_arch = oe.rust.arch_to_rust_arch(arch)
+
 if abi:
-arch_abi = "{}-{}".format(arch, abi)
+arch_abi = "{}-{}".format(rust_arch, abi)
 else:
-arch_abi = arch
+arch_abi = rust_arch
 
 features = features or d.getVarFlag('FEATURES', arch_abi) or ""
 features = features.strip()
@@ -329,7 +331,7 @@ def rust_gen_target(d, thing, wd, features, cpu, arch, 
abi=""):
 tspec['target-pointer-width'] = d.getVarFlag('TARGET_POINTER_WIDTH', 
arch_abi)
 tspec['target-c-int-width'] = d.getVarFlag('TARGET_C_INT_WIDTH', arch_abi)
 tspec['target-endian'] = d.getVarFlag('TARGET_ENDIAN', arch_abi)
-tspec['arch'] = arch_to_rust_target_arch(arch)
+tspec['arch'] = arch_to_rust_target_arch(rust_arch)
 tspec['os'] = "linux"
 if "musl" in tspec['llvm-target']:
 tspec['env'] = "musl"
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162502): 
https://lists.openembedded.org/g/openembedded-core/message/162502
Mute This Topic: https://lists.openembedded.org/mt/89451431/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2 0/3] rust: Fix powerpc64le support

2022-02-28 Thread Andrew Jeffery 
Hello,

Here's v2 of what was previously an RFC series where I just slashed my
way through trying to get rust going out of the box on powerpc64le.

Thanks to some pointers from Alex that effort has been significantly
cleaned up.

v2 is no-longer RFC as I think I have a decent understanding of what's
going on now. The RFC series can be found here:

https://lore.kernel.org/openembedded-core/20220222035234.463162-1-and...@aj.id.au/

The changes in v2 include:

* Drop the incorrect attempts at refactoring
* Drop the (now unnecessary) install hack for libstd-rs
* Drop the patch that tried to avoid duplicate toml sections by instead
  fixing the build configuration

The bits that survived since the RFC were:

* The introduction of RUST_BUILD_ARCH to handle the snapshot artifacts
* The introduction of arch_to_rust_arch() in a new python library for
  rust

arch_to_rust_arch() is not just a rename of arch_to_rust_target_arch()
as it was in the RFC. arch_to_rust_target_arch() stays for its existing
job - arch_to_rust_arch() appears alongside to do arch translations
earlier in the process. I'm not wedded to 'arch_to_rust_arch()' as a
name, if someone has a better color for the bikeshed then suggest away. 

Finally, I've re-posted the patch adding the snapshot checksums for
powerpc64le in case there is any enthusiasm for applying it. It's okay
if not, we can maintain that in e.g. OpenBMC in a bbappend if necessary.

Please review!

Andrew Jeffery (3):
  rust: Introduce arch_to_rust_arch()
  rust: Introduce RUST_BUILD_ARCH
  rust: Add snapshot checksums for powerpc64le

 meta/classes/base.bbclass|  2 +-
 meta/classes/rust-common.bbclass |  6 +-
 meta/lib/oe/rust.py  |  5 +
 meta/recipes-devtools/rust/rust-common.inc   |  8 +---
 meta/recipes-devtools/rust/rust-snapshot.inc | 16 ++--
 meta/recipes-devtools/rust/rust.inc  |  2 +-
 6 files changed, 27 insertions(+), 12 deletions(-)
 create mode 100644 meta/lib/oe/rust.py

-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162501): 
https://lists.openembedded.org/g/openembedded-core/message/162501
Mute This Topic: https://lists.openembedded.org/mt/89451430/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [RFC PATCH 6/8] rust: Mitigate duplicate sections on matching architectures

2022-02-28 Thread Andrew Jeffery 


On Mon, 28 Feb 2022, at 18:51, Alexander Kanavin wrote:
> On Mon, 28 Feb 2022 at 01:13, Andrew Jeffery  wrote:
>> Okay, so the root cause of this was I was setting RUST_{HOST,TARGET}_SYS
>> to "powerpc64le-unknown-linux-gnu", which matched RUST_BUILD_SYS. I did
>> that because rustc seems to be quite unhappy when supplied with
>> `--target ppc64le-linux` or `--target powerpc64le-linux'. I'm trying to
>> understand why, but I'm struggling because rustc seems just fine with
>> `--target x86_64-linux` despite none of `ppc64le-linux`,
>> `powerpc64le-linux` nor `x86_64-linux` appearing in the `rustc --print
>> target-list` output that I could gather.
>>
>> How/why does `--target x86_64-linux` work?
>
> I think in the context of oe-core, all targets are custom ones,
> specified by writing out json files and directing rust to use them. So
> you need to do two things:
> 1. --print target-list is useless and irrelevant, as it only prints
> built-in targets, don't try it.

Ack, certainly experienced that :)

> 2. When there's a problem inspect what json files are in the sysroot,
> what they contain, and whether rust is able to find them.
> x86_64-linux.json is made specifically for building native items.

Thanks, this helped a lot. Before sending the previous mail I had poked 
around a bit and found the json support in rust, but hadn't put enough 
of the puzzle pieces together to make the picture clear. With your 
pointer here I've cut away most of the cruft in the series and am 
testing the rework now.

Andrew

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162455): 
https://lists.openembedded.org/g/openembedded-core/message/162455
Mute This Topic: https://lists.openembedded.org/mt/89310362/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [RFC PATCH 6/8] rust: Mitigate duplicate sections on matching architectures

2022-02-27 Thread Andrew Jeffery 


On Wed, 23 Feb 2022, at 11:08, Andrew Jeffery wrote:
> On Tue, 22 Feb 2022, at 20:27, Alexander Kanavin wrote:
>> This needs a better explanation. 
>
> Ack.
>
>>What is the problem and how is it being fixed?
>
> The immediate error was the build bailed out complaining of duplicate 
> sections in the config. Possibly this is an indication of a broken build 
> configuration rather than the code needing fixes

Okay, so the root cause of this was I was setting RUST_{HOST,TARGET}_SYS
to "powerpc64le-unknown-linux-gnu", which matched RUST_BUILD_SYS. I did
that because rustc seems to be quite unhappy when supplied with
`--target ppc64le-linux` or `--target powerpc64le-linux'. I'm trying to
understand why, but I'm struggling because rustc seems just fine with
`--target x86_64-linux` despite none of `ppc64le-linux`,
`powerpc64le-linux` nor `x86_64-linux` appearing in the `rustc --print
target-list` output that I could gather.

How/why does `--target x86_64-linux` work?

Andrew

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162446): 
https://lists.openembedded.org/g/openembedded-core/message/162446
Mute This Topic: https://lists.openembedded.org/mt/89310362/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [RFC PATCH 1/8] rust: Migrate arch_to_rust_target_arch() to rust-common class

2022-02-22 Thread Andrew Jeffery 


On Tue, 22 Feb 2022, at 20:35, Richard Purdie wrote:
> On Tue, 2022-02-22 at 14:22 +1030, Andrew Jeffery wrote:
>> This will allow us to use it elsewhere for architecture name
>> translation. This move is motivated by powerpc64le support.
>> 
>> Signed-off-by: Andrew Jeffery 
>> ---
>>  meta/classes/rust-common.bbclass   | 16 
>>  meta/recipes-devtools/rust/rust-common.inc | 16 
>>  2 files changed, 16 insertions(+), 16 deletions(-)
>> 
>> diff --git a/meta/classes/rust-common.bbclass 
>> b/meta/classes/rust-common.bbclass
>> index 98d65970e8c0..2f2a31867ad0 100644
>> --- a/meta/classes/rust-common.bbclass
>> +++ b/meta/classes/rust-common.bbclass
>> @@ -1,5 +1,21 @@
>>  inherit python3native
>>  
>> +# Convert a normal arch (HOST_ARCH, TARGET_ARCH, BUILD_ARCH, etc) to 
>> something
>> +# rust's internals won't choke on.
>> +def arch_to_rust_target_arch(arch):
>> +if arch == "i586" or arch == "i686":
>> +return "x86"
>> +elif arch == "mipsel":
>> +return "mips"
>> +elif arch == "mip64sel":
>> +return "mips64"
>> +elif arch == "armv7":
>> +return "arm"
>> +elif arch == "powerpc64le":
>> +return "powerpc64"
>> +else:
>> +return arch
>> +
>>  # Common variables used by all Rust builds
>>  export rustlibdir = "${libdir}/rust"
>>  FILES:${PN} += "${rustlibdir}/*.so"
>
>
> If we're moving this, it may be a good candidate to move to a new
> meta/lib/oe/rust.py python function library for rust. I appreciate that is
> slightly move involved and will likely need the imports in base.bbclass to be
> tweaked but is probably the better long term fix.

I'll take a look.

Andrew

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162237): 
https://lists.openembedded.org/g/openembedded-core/message/162237
Mute This Topic: https://lists.openembedded.org/mt/89310355/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [RFC PATCH 6/8] rust: Mitigate duplicate sections on matching architectures

2022-02-22 Thread Andrew Jeffery 


On Tue, 22 Feb 2022, at 20:27, Alexander Kanavin wrote:
> This needs a better explanation. 

Ack.

>What is the problem and how is it being fixed?

The immediate error was the build bailed out complaining of duplicate 
sections in the config. Possibly this is an indication of a broken build 
configuration rather than the code needing fixes, but this is how I 
made the problem go away. As mentioned I kind of just slashed my way 
though everything. It deserves some closer analysis like you stated 
above.

Let me take some time to get a better grip on what's happening here.

Andrew

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162236): 
https://lists.openembedded.org/g/openembedded-core/message/162236
Mute This Topic: https://lists.openembedded.org/mt/89310362/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [RFC PATCH 7/8] rust: Add snapshot checksums for powerpc64le

2022-02-22 Thread Andrew Jeffery 


On Wed, 23 Feb 2022, at 10:33, Richard Purdie wrote:
> On Wed, 2022-02-23 at 10:19 +1030, Andrew Jeffery wrote:
>> 
>> On Tue, 22 Feb 2022, at 22:58, Richard Purdie wrote:
>> > On Tue, 2022-02-22 at 10:59 +0100, Alexander Kanavin wrote:
>> > > I have to note that YP does not support ppc systems as build hosts;
>> > > can this be kept in a bbappend?
>> > 
>> > It isn't official but there are obviously people using it. I think we 
>> > should try
>> > and do something in core but there is a question of how we maintain this 
>> > given
>> > our infrastructure/tests don't cover it :(
>> 
>> That's fair. Is it acceptable that it's tested by proxy in OpenBMC if 
>> we can't work out anything else for YP CI? I don't expect anyone 
>> maintaining the rust support to test ppc64le explicitly if they don't 
>> have access. I'd be happy if the ppc64le checksums were just updated 
>> along with the rest whenever the snapshots are bumped.
>
> The challenge is we have no tooling or support for "bumping" those values. 

Yeah, that's familiar, when I sent the initial patch fixing the URLs I 
hacked some stuff to force the BUILD_ARCH value to ppc64le on my x86-64 
laptop. That's not a scalable approach.

Not having the tooling seems reasonable, as having it does kinda 
suggest you'll try to maintain things you can't test. Even though I'm 
trying to argue for that, again, it's not scalable and I understand the 
push-back :)

> We
> spot issues with the other two build architectures since the autobuilder tests
> them.
>
> There are probably some tricks we could play to handle this. The challenge is
> then that someone needs to take the time to write something to handle this and
> communicate it to the maintainers so they know to use it. We're struggling to 
> do
> all the things like this we'd like to and that leads back to Alex's concern.

I understand.

I have pointed Alex at some resources to access ppc64le systems:

https://lore.kernel.org/openembedded-core/ee6810ac-3c22-45b0-ac49-e35b38e0f...@www.fastmail.com/

But if that's too much fuss then we can maintain the checksums in a 
bbappend in OpenBMC like has been suggested.

Andrew

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162235): 
https://lists.openembedded.org/g/openembedded-core/message/162235
Mute This Topic: https://lists.openembedded.org/mt/89310363/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [RFC PATCH 7/8] rust: Add snapshot checksums for powerpc64le

2022-02-22 Thread Andrew Jeffery 


On Wed, 23 Feb 2022, at 00:53, Alexander Kanavin wrote:
> On Tue, 22 Feb 2022 at 13:28, Richard Purdie
>  wrote:
>>
>> On Tue, 2022-02-22 at 10:59 +0100, Alexander Kanavin wrote:
>> > I have to note that YP does not support ppc systems as build hosts;
>> > can this be kept in a bbappend?
>>
>> It isn't official but there are obviously people using it. I think we should 
>> try
>> and do something in core but there is a question of how we maintain this 
>> given
>> our infrastructure/tests don't cover it :(
>
> Worse yet, there is no way to test this locally either.  If the ppc64
> binary tarball checksums are added to the core rust recipe, presumably
> I'd be expected to update them together with x86 and arm64 binary
> checksums on version updates, but I'd have to do this completely
> blindly with no testing of any kind :( That's why I am asking to keep
> them in an external bbappend.
>
> Andrew, how hard is it to obtain a shell on ppc64 machines nowadays?

(I work for IBM Power Systems)

IBM have partnered with Oregon State University to provide access to 
ppc64le machines:

* https://osuosl.org/services/powerdev/
* https://power-developer.mybluemix.net/#hardware

You can request access to the OSU setup:

* For a shell: https://osuosl.org/services/powerdev/request_hosting/
* For CI: https://osuosl.org/services/powerdev/request_powerci/

So there are some forms. I'm not sure where the bar sits for you with 
respect to how hard it is to go this route, but feel free to reply to 
me privately or via andre...@au1.ibm.com if you have further questions 
about setting something up on the OSU OSL infrastructure.

Andrew

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162234): 
https://lists.openembedded.org/g/openembedded-core/message/162234
Mute This Topic: https://lists.openembedded.org/mt/89310363/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [RFC PATCH 7/8] rust: Add snapshot checksums for powerpc64le

2022-02-22 Thread Andrew Jeffery 


On Tue, 22 Feb 2022, at 22:58, Richard Purdie wrote:
> On Tue, 2022-02-22 at 10:59 +0100, Alexander Kanavin wrote:
>> I have to note that YP does not support ppc systems as build hosts;
>> can this be kept in a bbappend?
>
> It isn't official but there are obviously people using it. I think we should 
> try
> and do something in core but there is a question of how we maintain this given
> our infrastructure/tests don't cover it :(

That's fair. Is it acceptable that it's tested by proxy in OpenBMC if 
we can't work out anything else for YP CI? I don't expect anyone 
maintaining the rust support to test ppc64le explicitly if they don't 
have access. I'd be happy if the ppc64le checksums were just updated 
along with the rest whenever the snapshots are bumped.

Andrew

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162232): 
https://lists.openembedded.org/g/openembedded-core/message/162232
Mute This Topic: https://lists.openembedded.org/mt/89310363/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [RFC PATCH 7/8] rust: Add snapshot checksums for powerpc64le

2022-02-22 Thread Andrew Jeffery 


On Wed, 23 Feb 2022, at 05:04, Khem Raj wrote:
> On Tue, Feb 22, 2022 at 6:24 AM Alexander Kanavin
>  wrote:
>>
>> On Tue, 22 Feb 2022 at 13:28, Richard Purdie
>>  wrote:
>> >
>> > On Tue, 2022-02-22 at 10:59 +0100, Alexander Kanavin wrote:
>> > > I have to note that YP does not support ppc systems as build hosts;
>> > > can this be kept in a bbappend?
>> >
>> > It isn't official but there are obviously people using it. I think we 
>> > should try
>> > and do something in core but there is a question of how we maintain this 
>> > given
>> > our infrastructure/tests don't cover it :(
>>
>> Worse yet, there is no way to test this locally either.  If the ppc64
>> binary tarball checksums are added to the core rust recipe, presumably
>> I'd be expected to update them together with x86 and arm64 binary
>> checksums on version updates, but I'd have to do this completely
>> blindly with no testing of any kind :(
>
> as long as it does not impede main testing I would think thats ok and
> we can expect the OE community
> members like Andrew to test this and report issues or better fix them

Well, hopefully I've shown I'm at least willing to try fix things :D

And yeah, my preference would be that the ppc64le checksums are just 
bumped along with the rest, but without any explicit testing beyond 
that. I understand that I'm not the maintainer here so will go along 
with whatever approach is chosen, but keeping them here feels like 
we're at least solving the problem in a consistent spot.

As mentioned in the cover letter we found this issue via the ppc64le CI 
machines used in OpenBMC. OpenBMC tries to integrate upstream YP 
changes every fortnight or so. That's obviously not as ideal as ppc64le 
resources dedicated to YP, but I think this provides enough feedback 
that things won't completely rot.

If a bump does cause issues I'll try to resolve them as soon as possible.

Andrew

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162230): 
https://lists.openembedded.org/g/openembedded-core/message/162230
Mute This Topic: https://lists.openembedded.org/mt/89310363/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [meta-oe][PATCH] meta-openembedded: Fix CARGO_BUILD_TARGET

2022-02-21 Thread Andrew Jeffery 
On modern Power systems `uname -m` yields 'ppc64le' but Rust knows the
architecture as 'powerpc64le'. Use RUST_HOST_SYS rather than HOST_SYS to
ensure we have the right arch name.

Change-Id: I63640e39d29a00c3101425213ba4b1d248ac9ace
Signed-off-by: Andrew Jeffery 
---
 meta-python/classes/pyo3.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-python/classes/pyo3.bbclass b/meta-python/classes/pyo3.bbclass
index 6ce21329c2ef..c2e8e7b385c0 100644
--- a/meta-python/classes/pyo3.bbclass
+++ b/meta-python/classes/pyo3.bbclass
@@ -3,12 +3,12 @@
 # and setuptools_rust properly set up the environment for cross compilation
 #
 
-inherit cargo python3-dir siteinfo
+inherit cargo python3-dir siteinfo rust-common
 
 export PYO3_CROSS="1"
 export PYO3_CROSS_PYTHON_VERSION="${PYTHON_BASEVERSION}"
 export PYO3_CROSS_LIB_DIR="${STAGING_LIBDIR}"
-export CARGO_BUILD_TARGET="${HOST_SYS}"
+export CARGO_BUILD_TARGET="${RUST_HOST_SYS}"
 export RUSTFLAGS
 export PYO3_PYTHON="${PYTHON}"
 export PYO3_CONFIG_FILE="${WORKDIR}/pyo3.config"
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162123): 
https://lists.openembedded.org/g/openembedded-core/message/162123
Mute This Topic: https://lists.openembedded.org/mt/89310406/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 8/8] rust: Introduce RUST_BUILD_ARCH

2022-02-21 Thread Andrew Jeffery 
On modern Power systems `uname -m` yields 'ppc64le' while the toolchain
knows the architecture as 'powerpc64le'. Provide a mapping from one to
the other to download the correct snapshot artifacts.

Signed-off-by: Andrew Jeffery 
---
 meta/classes/rust-common.bbclass |  3 +++
 meta/recipes-devtools/rust/rust-snapshot.inc | 12 ++--
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/meta/classes/rust-common.bbclass b/meta/classes/rust-common.bbclass
index 58ece01097c8..2ee7e178e536 100644
--- a/meta/classes/rust-common.bbclass
+++ b/meta/classes/rust-common.bbclass
@@ -107,6 +107,9 @@ def rust_base_triple(d, thing):
 libc = bb.utils.contains('TUNE_FEATURES', 'callconvention-hard', 'hf', 
'', d)
 return arch + vendor + '-' + os + libc
 
+# In some cases uname and the toolchain differ on their idea of the arch name
+RUST_BUILD_ARCH = "${@arch_to_rust_arch(d.getVar('BUILD_ARCH'))}"
+
 # Naming explanation
 # Yocto
 # - BUILD_SYS - Yocto triple of the build environment
diff --git a/meta/recipes-devtools/rust/rust-snapshot.inc 
b/meta/recipes-devtools/rust/rust-snapshot.inc
index d6ffe92d07ee..d0c05aec7866 100644
--- a/meta/recipes-devtools/rust/rust-snapshot.inc
+++ b/meta/recipes-devtools/rust/rust-snapshot.inc
@@ -19,11 +19,11 @@ SRC_URI[rustc-snapshot-powerpc64le.sha256sum] = 
"f43cb99109c3438c77c7079cdce4673
 SRC_URI[cargo-snapshot-powerpc64le.sha256sum] = 
"599cf1b5a8cdbf76d591621bc9222aefa60e2f5fd378ae71c4dcf4514c47122e"
 
 SRC_URI += " \
-
https://static.rust-lang.org/dist/${RUST_STD_SNAPSHOT}.tar.xz;name=rust-std-snapshot-${BUILD_ARCH};subdir=rust-snapshot-components
 \
-
https://static.rust-lang.org/dist/${RUSTC_SNAPSHOT}.tar.xz;name=rustc-snapshot-${BUILD_ARCH};subdir=rust-snapshot-components
 \
-
https://static.rust-lang.org/dist/${CARGO_SNAPSHOT}.tar.xz;name=cargo-snapshot-${BUILD_ARCH};subdir=rust-snapshot-components
 \
+
https://static.rust-lang.org/dist/${RUST_STD_SNAPSHOT}.tar.xz;name=rust-std-snapshot-${RUST_BUILD_ARCH};subdir=rust-snapshot-components
 \
+
https://static.rust-lang.org/dist/${RUSTC_SNAPSHOT}.tar.xz;name=rustc-snapshot-${RUST_BUILD_ARCH};subdir=rust-snapshot-components
 \
+
https://static.rust-lang.org/dist/${CARGO_SNAPSHOT}.tar.xz;name=cargo-snapshot-${RUST_BUILD_ARCH};subdir=rust-snapshot-components
 \
 "
 
-RUST_STD_SNAPSHOT = "rust-std-${RS_VERSION}-${BUILD_ARCH}-unknown-linux-gnu"
-RUSTC_SNAPSHOT = "rustc-${RS_VERSION}-${BUILD_ARCH}-unknown-linux-gnu"
-CARGO_SNAPSHOT = "cargo-${CARGO_VERSION}-${BUILD_ARCH}-unknown-linux-gnu"
+RUST_STD_SNAPSHOT = 
"rust-std-${RS_VERSION}-${RUST_BUILD_ARCH}-unknown-linux-gnu"
+RUSTC_SNAPSHOT = "rustc-${RS_VERSION}-${RUST_BUILD_ARCH}-unknown-linux-gnu"
+CARGO_SNAPSHOT = "cargo-${CARGO_VERSION}-${RUST_BUILD_ARCH}-unknown-linux-gnu"
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162122): 
https://lists.openembedded.org/g/openembedded-core/message/162122
Mute This Topic: https://lists.openembedded.org/mt/89310365/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 7/8] rust: Add snapshot checksums for powerpc64le

2022-02-21 Thread Andrew Jeffery 
Signed-off-by: Andrew Jeffery 
---
 meta/recipes-devtools/rust/rust-snapshot.inc | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-devtools/rust/rust-snapshot.inc 
b/meta/recipes-devtools/rust/rust-snapshot.inc
index 74b558262f62..d6ffe92d07ee 100644
--- a/meta/recipes-devtools/rust/rust-snapshot.inc
+++ b/meta/recipes-devtools/rust/rust-snapshot.inc
@@ -14,6 +14,10 @@ SRC_URI[rust-std-snapshot-aarch64.sha256sum] = 
"3618da916a0f92f241cf1d67d04bb578
 SRC_URI[rustc-snapshot-aarch64.sha256sum] = 
"f26811e48d03c56c125de03d389e1ae7c6df36990953c1670c6a5676bc12d4cb"
 SRC_URI[cargo-snapshot-aarch64.sha256sum] = 
"6d11cd94618d80cda273eeeae7285980445f61a49ebacc616777b482a41cbf3f"
 
+SRC_URI[rust-std-snapshot-powerpc64le.sha256sum] = 
"fc07eb3e9f3d227428cc5b53ca868e3de375bc198ce4dce7b87a9246e6fec81a"
+SRC_URI[rustc-snapshot-powerpc64le.sha256sum] = 
"f43cb99109c3438c77c7079cdce4673df3320e310158e0b4d949c1babc4300fc"
+SRC_URI[cargo-snapshot-powerpc64le.sha256sum] = 
"599cf1b5a8cdbf76d591621bc9222aefa60e2f5fd378ae71c4dcf4514c47122e"
+
 SRC_URI += " \
 
https://static.rust-lang.org/dist/${RUST_STD_SNAPSHOT}.tar.xz;name=rust-std-snapshot-${BUILD_ARCH};subdir=rust-snapshot-components
 \
 
https://static.rust-lang.org/dist/${RUSTC_SNAPSHOT}.tar.xz;name=rustc-snapshot-${BUILD_ARCH};subdir=rust-snapshot-components
 \
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162121): 
https://lists.openembedded.org/g/openembedded-core/message/162121
Mute This Topic: https://lists.openembedded.org/mt/89310363/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 6/8] rust: Mitigate duplicate sections on matching architectures

2022-02-21 Thread Andrew Jeffery 
This seemed to be an issue for Power once the arch mappings were fixed
(by a patch later in this series).

Signed-off-by: Andrew Jeffery 
---
 meta/recipes-devtools/rust/rust.inc | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/meta/recipes-devtools/rust/rust.inc 
b/meta/recipes-devtools/rust/rust.inc
index cc0730e9cd2d..fd934082bddf 100644
--- a/meta/recipes-devtools/rust/rust.inc
+++ b/meta/recipes-devtools/rust/rust.inc
@@ -35,8 +35,11 @@ setup_cargo_environment () {
 # Later stages are build for the native target (i.e. target.x86_64-linux)
 cargo_common_do_configure
 
-printf '[target.%s]\n' "${SNAPSHOT_BUILD_SYS}" >> ${CARGO_HOME}/config
-printf "linker = '%s'\n" "${RUST_BUILD_CCLD}" >> ${CARGO_HOME}/config
+if [ ${SNAPSHOT_BUILD_SYS} != ${RUST_BUILD_SYS} ]
+then
+printf '[target.%s]\n' "${SNAPSHOT_BUILD_SYS}" >> ${CARGO_HOME}/config
+printf "linker = '%s'\n" "${RUST_BUILD_CCLD}" >> ${CARGO_HOME}/config
+fi
 }
 
 include rust-common.inc
@@ -88,15 +91,16 @@ python do_configure() {
 config.set(target_section, "cxx", e(d.expand("${RUST_TARGET_CXX}")))
 config.set(target_section, "cc", e(d.expand("${RUST_TARGET_CC}")))
 
-# If we don't do this rust-native will compile it's own llvm for BUILD.
-# [target.${BUILD_ARCH}-unknown-linux-gnu]
-target_section = "target.{}".format(d.getVar('SNAPSHOT_BUILD_SYS', True))
-config.add_section(target_section)
+if (d.getVar('SNAPSHOT_BUILD_SYS') != d.getVar('RUST_TARGET_SYS')):
+# If we don't do this rust-native will compile it's own llvm for BUILD.
+# [target.${BUILD_ARCH}-unknown-linux-gnu]
+target_section = "target.{}".format(d.getVar('SNAPSHOT_BUILD_SYS', 
True))
+config.add_section(target_section)
 
-config.set(target_section, "llvm-config", e(llvm_config))
+config.set(target_section, "llvm-config", e(llvm_config))
 
-config.set(target_section, "cxx", e(d.expand("${RUST_BUILD_CXX}")))
-config.set(target_section, "cc", e(d.expand("${RUST_BUILD_CC}")))
+config.set(target_section, "cxx", e(d.expand("${RUST_BUILD_CXX}")))
+config.set(target_section, "cc", e(d.expand("${RUST_BUILD_CC}")))
 
 # [rust]
 config.add_section("rust")
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162120): 
https://lists.openembedded.org/g/openembedded-core/message/162120
Mute This Topic: https://lists.openembedded.org/mt/89310362/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 4/8] rust: Consistently use RUST_{BUILD,HOST,TARGET}_{ARCH,SYS}

2022-02-21 Thread Andrew Jeffery 
With achitecture name translation, the RUST_-prefixed variables and
their unadorned equivalents may not be the same.

Signed-off-by: Andrew Jeffery 
---
 meta/classes/cargo.bbclass|  4 ++--
 meta/classes/cargo_common.bbclass |  6 ++---
 meta/classes/rust-common.bbclass  |  2 +-
 meta/classes/rust.bbclass |  8 +++
 meta/recipes-devtools/rust/rust-common.inc| 10 
 .../rust/rust-cross-canadian-common.inc   |  6 ++---
 .../rust/rust-cross-canadian.inc  | 23 ++-
 meta/recipes-devtools/rust/rust-cross.inc |  2 +-
 meta/recipes-devtools/rust/rust.inc   | 16 ++---
 9 files changed, 40 insertions(+), 37 deletions(-)

diff --git a/meta/classes/cargo.bbclass b/meta/classes/cargo.bbclass
index 0ca38143c0b3..1507ff0e4ca1 100644
--- a/meta/classes/cargo.bbclass
+++ b/meta/classes/cargo.bbclass
@@ -31,12 +31,12 @@ MANIFEST_PATH ??= "${S}/${CARGO_SRC_DIR}/Cargo.toml"
 
 RUSTFLAGS ??= ""
 BUILD_MODE = "${@['--release', ''][d.getVar('DEBUG_BUILD') == '1']}"
-CARGO_BUILD_FLAGS = "-v --target ${HOST_SYS} ${BUILD_MODE} 
--manifest-path=${MANIFEST_PATH}"
+CARGO_BUILD_FLAGS = "-v --target ${RUST_HOST_SYS} ${BUILD_MODE} 
--manifest-path=${MANIFEST_PATH}"
 
 # This is based on the content of CARGO_BUILD_FLAGS and generally will need to
 # change if CARGO_BUILD_FLAGS changes.
 BUILD_DIR = "${@['release', 'debug'][d.getVar('DEBUG_BUILD') == '1']}"
-CARGO_TARGET_SUBDIR="${HOST_SYS}/${BUILD_DIR}"
+CARGO_TARGET_SUBDIR="${RUST_HOST_SYS}/${BUILD_DIR}"
 oe_cargo_build () {
export RUSTFLAGS="${RUSTFLAGS}"
export RUST_TARGET_PATH="${RUST_TARGET_PATH}"
diff --git a/meta/classes/cargo_common.bbclass 
b/meta/classes/cargo_common.bbclass
index 90fad7541530..103240ce491e 100644
--- a/meta/classes/cargo_common.bbclass
+++ b/meta/classes/cargo_common.bbclass
@@ -69,15 +69,15 @@ cargo_common_do_configure () {
cat <<- EOF >> ${CARGO_HOME}/config
 
# HOST_SYS
-   [target.${HOST_SYS}]
+   [target.${RUST_HOST_SYS}]
linker = "${CARGO_RUST_TARGET_CCLD}"
EOF
 
-   if [ "${HOST_SYS}" != "${BUILD_SYS}" ]; then
+   if [ "${RUST_HOST_SYS}" != "${RUST_BUILD_SYS}" ]; then
cat <<- EOF >> ${CARGO_HOME}/config
 
# BUILD_SYS
-   [target.${BUILD_SYS}]
+   [target.${RUST_BUILD_SYS}]
linker = "${RUST_BUILD_CCLD}"
EOF
fi
diff --git a/meta/classes/rust-common.bbclass b/meta/classes/rust-common.bbclass
index 3c7d133f0445..58ece01097c8 100644
--- a/meta/classes/rust-common.bbclass
+++ b/meta/classes/rust-common.bbclass
@@ -83,7 +83,7 @@ def rust_base_triple(d, thing):
 if thing == "TARGET" and target_is_armv7(d):
 arch = "armv7"
 else:
-arch = d.getVar('{}_ARCH'.format(thing))
+arch = arch_to_rust_arch(d.getVar('{}_ARCH'.format(thing)))
 
 # All the Yocto targets are Linux and are 'unknown'
 vendor = "-unknown"
diff --git a/meta/classes/rust.bbclass b/meta/classes/rust.bbclass
index 5c8938d09fe5..bb1276215b0f 100644
--- a/meta/classes/rust.bbclass
+++ b/meta/classes/rust.bbclass
@@ -2,14 +2,14 @@ inherit rust-common
 
 RUSTC = "rustc"
 
-RUSTC_ARCHFLAGS += "--target=${HOST_SYS} ${RUSTFLAGS}"
+RUSTC_ARCHFLAGS += "--target=${RUST_HOST_SYS} ${RUSTFLAGS}"
 
 def rust_base_dep(d):
 # Taken from meta/classes/base.bbclass `base_dep_prepend` and modified to
 # use rust instead of gcc
 deps = ""
 if not d.getVar('INHIBIT_DEFAULT_RUST_DEPS'):
-if (d.getVar('HOST_SYS') != d.getVar('BUILD_SYS')):
+if (d.getVar('RUST_HOST_SYS') != d.getVar('RUST_BUILD_SYS')):
 deps += " virtual/${TARGET_PREFIX}rust ${RUSTLIB_DEP}"
 else:
 deps += " rust-native"
@@ -37,9 +37,9 @@ HOST_CFLAGS   ?= "${CFLAGS}"
 HOST_CXXFLAGS ?= "${CXXFLAGS}"
 HOST_CPPFLAGS ?= "${CPPFLAGS}"
 
-rustlib_suffix="${TUNE_ARCH}${TARGET_VENDOR}-${TARGET_OS}/rustlib/${HOST_SYS}/lib"
+rustlib_suffix="${TUNE_ARCH}${TARGET_VENDOR}-${TARGET_OS}/rustlib/${RUST_HOST_SYS}/lib"
 # Native sysroot standard library path
 rustlib_src="${prefix}/lib/${rustlib_suffix}"
 # Host sysroot standard library path
 rustlib="${libdir}/${rustlib_suffix}"
-rustlib:class-native="${libdir}/rustlib/${BUILD_SYS}/lib"
+rustlib:class-native="${libdir}/rustlib/${RUST_BUILD_SYS}/lib"
diff --git a/meta/recipes-devtools/rust/rust-common.inc 
b/meta/recipes-devtools/rust/rust-common.inc
index 4b758260d276..8ba78b978708 100644
--- a/meta/recipes-devtools/rust/rust-common.inc
+++ b/meta/recipes-devtools/rust/rus

[OE-core] [RFC PATCH 5/8] rust: libstd-rs: Install deps under {RUST_,}TARGET_SYS mismatch

2022-02-21 Thread Andrew Jeffery 
The architecture mangling gets a bit too much here. Use globs to paper
over the problem.

Signed-off-by: Andrew Jeffery 
---
 meta/recipes-devtools/rust/libstd-rs.inc | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/rust/libstd-rs.inc 
b/meta/recipes-devtools/rust/libstd-rs.inc
index 987956344a24..e94fb8d5612e 100644
--- a/meta/recipes-devtools/rust/libstd-rs.inc
+++ b/meta/recipes-devtools/rust/libstd-rs.inc
@@ -35,6 +35,14 @@ do_install () {
 # With the incremental build support added in 1.24, the libstd deps 
directory also includes dependency
 # files that get installed. Those are really only needed to incrementally 
rebuild the libstd library
 # itself and don't need to be installed.
-rm -f ${B}/${TARGET_SYS}/${BUILD_DIR}/deps/*.d
-cp ${B}/${TARGET_SYS}/${BUILD_DIR}/deps/* ${D}${rustlibdir}
+#
+# ${B} contains two directories, one for the target architecture and one 
for the build mode
+# (e.g. "release"). In some cases (e.g. ARMv7) the build directory matches 
neither ${TARGET_SYS}
+# (due to "unknown" vendor from rust_base_triple()) nor ${RUST_TARGET_SYS} 
(due to architecture
+# name mangling in rust_base_triple()). Further, rust_base_triple() always 
assumes a linux
+# OS, so exploit both "unknown" and "linux" in a triple glob to select the 
right source
+# directory.
+DEPS=${B}/*-unknown-linux-*/${BUILD_DIR}/deps
+rm -f ${DEPS}/*.d
+cp ${DEPS}/* ${D}${rustlibdir}
 }
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162119): 
https://lists.openembedded.org/g/openembedded-core/message/162119
Mute This Topic: https://lists.openembedded.org/mt/89310361/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 3/8] rust: Handle Power arch variants in arch_to_rust_arch()

2022-02-21 Thread Andrew Jeffery 
Modern Power ecosystems can be either BE or LE, so handle both. Further,
rust understands these as "powerpc64" and "powerpc64le" respectively.

Signed-off-by: Andrew Jeffery 
---
 meta/classes/rust-common.bbclass   | 4 +++-
 meta/recipes-devtools/rust/rust-common.inc | 3 ++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/classes/rust-common.bbclass b/meta/classes/rust-common.bbclass
index e50d606ce26f..3c7d133f0445 100644
--- a/meta/classes/rust-common.bbclass
+++ b/meta/classes/rust-common.bbclass
@@ -11,8 +11,10 @@ def arch_to_rust_arch(arch):
 return "mips64"
 elif arch == "armv7":
 return "arm"
-elif arch == "powerpc64le":
+elif arch == "ppc64":
 return "powerpc64"
+elif arch == "ppc64le":
+return "powerpc64le"
 else:
 return arch
 
diff --git a/meta/recipes-devtools/rust/rust-common.inc 
b/meta/recipes-devtools/rust/rust-common.inc
index c36d836fcf41..4b758260d276 100644
--- a/meta/recipes-devtools/rust/rust-common.inc
+++ b/meta/recipes-devtools/rust/rust-common.inc
@@ -265,7 +265,8 @@ def llvm_cpu(d):
 trans['x86-64'] = "x86-64"
 trans['i686'] = "i686"
 trans['i586'] = "i586"
-trans['powerpc'] = "powerpc"
+trans['powerpc64'] = "powerpc"
+trans['powerpc64le'] = "powerpc"
 trans['mips64'] = "mips64"
 trans['mips64el'] = "mips64"
 trans['riscv64'] = "generic-rv64"
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162117): 
https://lists.openembedded.org/g/openembedded-core/message/162117
Mute This Topic: https://lists.openembedded.org/mt/89310359/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 1/8] rust: Migrate arch_to_rust_target_arch() to rust-common class

2022-02-21 Thread Andrew Jeffery 
This will allow us to use it elsewhere for architecture name
translation. This move is motivated by powerpc64le support.

Signed-off-by: Andrew Jeffery 
---
 meta/classes/rust-common.bbclass   | 16 
 meta/recipes-devtools/rust/rust-common.inc | 16 
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/meta/classes/rust-common.bbclass b/meta/classes/rust-common.bbclass
index 98d65970e8c0..2f2a31867ad0 100644
--- a/meta/classes/rust-common.bbclass
+++ b/meta/classes/rust-common.bbclass
@@ -1,5 +1,21 @@
 inherit python3native
 
+# Convert a normal arch (HOST_ARCH, TARGET_ARCH, BUILD_ARCH, etc) to something
+# rust's internals won't choke on.
+def arch_to_rust_target_arch(arch):
+if arch == "i586" or arch == "i686":
+return "x86"
+elif arch == "mipsel":
+return "mips"
+elif arch == "mip64sel":
+return "mips64"
+elif arch == "armv7":
+return "arm"
+elif arch == "powerpc64le":
+return "powerpc64"
+else:
+return arch
+
 # Common variables used by all Rust builds
 export rustlibdir = "${libdir}/rust"
 FILES:${PN} += "${rustlibdir}/*.so"
diff --git a/meta/recipes-devtools/rust/rust-common.inc 
b/meta/recipes-devtools/rust/rust-common.inc
index c9786376..742933f1bd22 100644
--- a/meta/recipes-devtools/rust/rust-common.inc
+++ b/meta/recipes-devtools/rust/rust-common.inc
@@ -254,22 +254,6 @@ def sys_for(d, thing):
 def prefix_for(d, thing):
 return d.getVar('{}_PREFIX'.format(thing))
 
-# Convert a normal arch (HOST_ARCH, TARGET_ARCH, BUILD_ARCH, etc) to something
-# rust's internals won't choke on.
-def arch_to_rust_target_arch(arch):
-if arch == "i586" or arch == "i686":
-return "x86"
-elif arch == "mipsel":
-return "mips"
-elif arch == "mip64sel":
-return "mips64"
-elif arch == "armv7":
-return "arm"
-elif arch == "powerpc64le":
-return "powerpc64"
-else:
-return arch
-
 # generates our target CPU value
 def llvm_cpu(d):
 cpu = d.getVar('PACKAGE_ARCH')
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162115): 
https://lists.openembedded.org/g/openembedded-core/message/162115
Mute This Topic: https://lists.openembedded.org/mt/89310355/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 2/8] rust: Rename arch_to_rust_target_arch() for generality

2022-02-21 Thread Andrew Jeffery 
It's not just for translating TARGET names, but any of BUILD, HOST or
TARGET.

Signed-off-by: Andrew Jeffery 
---
 meta/classes/rust-common.bbclass   | 2 +-
 meta/recipes-devtools/rust/rust-common.inc | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/rust-common.bbclass b/meta/classes/rust-common.bbclass
index 2f2a31867ad0..e50d606ce26f 100644
--- a/meta/classes/rust-common.bbclass
+++ b/meta/classes/rust-common.bbclass
@@ -2,7 +2,7 @@ inherit python3native
 
 # Convert a normal arch (HOST_ARCH, TARGET_ARCH, BUILD_ARCH, etc) to something
 # rust's internals won't choke on.
-def arch_to_rust_target_arch(arch):
+def arch_to_rust_arch(arch):
 if arch == "i586" or arch == "i686":
 return "x86"
 elif arch == "mipsel":
diff --git a/meta/recipes-devtools/rust/rust-common.inc 
b/meta/recipes-devtools/rust/rust-common.inc
index 742933f1bd22..c36d836fcf41 100644
--- a/meta/recipes-devtools/rust/rust-common.inc
+++ b/meta/recipes-devtools/rust/rust-common.inc
@@ -313,7 +313,7 @@ def rust_gen_target(d, thing, wd, features, cpu, arch, 
abi=""):
 tspec['target-pointer-width'] = d.getVarFlag('TARGET_POINTER_WIDTH', 
arch_abi)
 tspec['target-c-int-width'] = d.getVarFlag('TARGET_C_INT_WIDTH', arch_abi)
 tspec['target-endian'] = d.getVarFlag('TARGET_ENDIAN', arch_abi)
-tspec['arch'] = arch_to_rust_target_arch(arch)
+tspec['arch'] = arch_to_rust_arch(arch)
 tspec['os'] = "linux"
 if "musl" in tspec['llvm-target']:
 tspec['env'] = "musl"
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162116): 
https://lists.openembedded.org/g/openembedded-core/message/162116
Mute This Topic: https://lists.openembedded.org/mt/89310358/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [RFC PATCH 0/8] rust: Fix powerpc64le support

2022-02-21 Thread Andrew Jeffery 
Hello,

This series was motivated by some CI failures we saw in OpenBMC on our
ppc64le build machines, driven by the python3-cryptography dependency of
the tpm2-pkcs11 package, pulled in via packagegroup-security-tpm2.

I previously sent an initial, wildly insufficient attempt that fixed the
immediate error of using a bad architecture name in the snapshot
download URLs:

https://lore.kernel.org/openembedded-core/20220218054315.169005-1-and...@aj.id.au/

Khem was on the money with his query, and pulling that thread led
to this unwieldy series. Together these patches (plus another for
meta-openembedded to fix CARGO_BUILD_TARGET) result in a successful
`bitbake python3-cryptography` targetting an ARMv7 machine (an ASPEED
AST2600 BMC SoC) on ppc64le and x86-64.

Please treat the patches with suspicion, I really just slashed my way
through it all until the build didn't fail, then tried to clean the
result up into a series that might be reviewable. Hence RFC.

Anyway, please take a look!

Andrew

Andrew Jeffery (8):
  rust: Migrate arch_to_rust_target_arch() to rust-common class
  rust: Rename arch_to_rust_target_arch() for generality
  rust: Handle Power arch variants in arch_to_rust_arch()
  rust: Consistently use RUST_{BUILD,HOST,TARGET}_{ARCH,SYS}
  rust: libstd-rs: Install deps under {RUST_,}TARGET_SYS mismatch
  rust: Mitigate duplicate sections on matching architectures
  rust: Add snapshot checksums for powerpc64le
  rust: Introduce RUST_BUILD_ARCH

 meta/classes/cargo.bbclass|  4 +-
 meta/classes/cargo_common.bbclass |  6 +--
 meta/classes/rust-common.bbclass  | 23 ++-
 meta/classes/rust.bbclass |  8 ++--
 meta/recipes-devtools/rust/libstd-rs.inc  | 12 +-
 meta/recipes-devtools/rust/rust-common.inc| 29 --
 .../rust/rust-cross-canadian-common.inc   |  6 +--
 .../rust/rust-cross-canadian.inc  | 23 +--
 meta/recipes-devtools/rust/rust-cross.inc |  2 +-
 meta/recipes-devtools/rust/rust-snapshot.inc  | 16 +---
 meta/recipes-devtools/rust/rust.inc   | 38 ++-
 11 files changed, 96 insertions(+), 71 deletions(-)

-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162114): 
https://lists.openembedded.org/g/openembedded-core/message/162114
Mute This Topic: https://lists.openembedded.org/mt/89310354/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] rust: Introduce RS_BUILD_ARCH to handle ppc64le

2022-02-18 Thread Andrew Jeffery 


On Fri, 18 Feb 2022, at 16:43, Khem Raj wrote:
> On Thu, Feb 17, 2022 at 9:43 PM Andrew Jeffery  wrote:
>>
>> On modern Power systems `uname -m` reports 'ppc64le'. However, Rust's
>> toolchain names the architecture 'powerpc64le'.
>>
>> Introduce RS_BUILD_ARCH to provide an indirection to fix this mismatch.
>>
>> I've tested each of the generated URIs for Power using the output from
>> `bitbake -e rust-native` and could successfully fetch the artifacts.
>>
> thanks
> can you also check if arch_to_rust_target_arch() in
> meta/recipes-devtools/rust/rust-common.inc
> is computing it right for ppc64le case ?

Yep, I'll poke at that.

Andrew

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161957): 
https://lists.openembedded.org/g/openembedded-core/message/161957
Mute This Topic: https://lists.openembedded.org/mt/89227468/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] rust: Introduce RS_BUILD_ARCH to handle ppc64le

2022-02-17 Thread Andrew Jeffery 
On modern Power systems `uname -m` reports 'ppc64le'. However, Rust's
toolchain names the architecture 'powerpc64le'.

Introduce RS_BUILD_ARCH to provide an indirection to fix this mismatch.

I've tested each of the generated URIs for Power using the output from
`bitbake -e rust-native` and could successfully fetch the artifacts.

Signed-off-by: Andrew Jeffery 
---
 meta/recipes-devtools/rust/rust-snapshot.inc | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-devtools/rust/rust-snapshot.inc 
b/meta/recipes-devtools/rust/rust-snapshot.inc
index 74b558262f62..9b309b6f330c 100644
--- a/meta/recipes-devtools/rust/rust-snapshot.inc
+++ b/meta/recipes-devtools/rust/rust-snapshot.inc
@@ -14,12 +14,20 @@ SRC_URI[rust-std-snapshot-aarch64.sha256sum] = 
"3618da916a0f92f241cf1d67d04bb578
 SRC_URI[rustc-snapshot-aarch64.sha256sum] = 
"f26811e48d03c56c125de03d389e1ae7c6df36990953c1670c6a5676bc12d4cb"
 SRC_URI[cargo-snapshot-aarch64.sha256sum] = 
"6d11cd94618d80cda273eeeae7285980445f61a49ebacc616777b482a41cbf3f"
 
+python () {
+build_arch = d.getVar('BUILD_ARCH')
+if build_arch == "ppc64le":
+d.setVar("RS_BUILD_ARCH", "powerpc64le")
+else:
+d.setVar("RS_BUILD_ARCH", build_arch)
+}
+
 SRC_URI += " \
-
https://static.rust-lang.org/dist/${RUST_STD_SNAPSHOT}.tar.xz;name=rust-std-snapshot-${BUILD_ARCH};subdir=rust-snapshot-components
 \
-
https://static.rust-lang.org/dist/${RUSTC_SNAPSHOT}.tar.xz;name=rustc-snapshot-${BUILD_ARCH};subdir=rust-snapshot-components
 \
-
https://static.rust-lang.org/dist/${CARGO_SNAPSHOT}.tar.xz;name=cargo-snapshot-${BUILD_ARCH};subdir=rust-snapshot-components
 \
+
https://static.rust-lang.org/dist/${RUST_STD_SNAPSHOT}.tar.xz;name=rust-std-snapshot-${RS_BUILD_ARCH};subdir=rust-snapshot-components
 \
+
https://static.rust-lang.org/dist/${RUSTC_SNAPSHOT}.tar.xz;name=rustc-snapshot-${RS_BUILD_ARCH};subdir=rust-snapshot-components
 \
+
https://static.rust-lang.org/dist/${CARGO_SNAPSHOT}.tar.xz;name=cargo-snapshot-${RS_BUILD_ARCH};subdir=rust-snapshot-components
 \
 "
 
-RUST_STD_SNAPSHOT = "rust-std-${RS_VERSION}-${BUILD_ARCH}-unknown-linux-gnu"
-RUSTC_SNAPSHOT = "rustc-${RS_VERSION}-${BUILD_ARCH}-unknown-linux-gnu"
-CARGO_SNAPSHOT = "cargo-${CARGO_VERSION}-${BUILD_ARCH}-unknown-linux-gnu"
+RUST_STD_SNAPSHOT = "rust-std-${RS_VERSION}-${RS_BUILD_ARCH}-unknown-linux-gnu"
+RUSTC_SNAPSHOT = "rustc-${RS_VERSION}-${RS_BUILD_ARCH}-unknown-linux-gnu"
+CARGO_SNAPSHOT = "cargo-${CARGO_VERSION}-${RS_BUILD_ARCH}-unknown-linux-gnu"
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161878): 
https://lists.openembedded.org/g/openembedded-core/message/161878
Mute This Topic: https://lists.openembedded.org/mt/89227468/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] dtc: Provide libfdt

2019-08-05 Thread Andrew Jeffery 



On Tue, 6 Aug 2019, at 02:08, Ross Burton wrote:
> On 05/08/2019 04:12, Andrew Jeffery wrote:
> > Applications are appearing that depend on parsing flattened devicetree
> > in userspace on target devices, e.g. pdbg[1]. Mark dtc as providing
> > libfdt so application recipes can depend on it.
> 
> Other recipes can just depend on dtc to get libftd build.

Alright, lets leave it that way.

Andrew
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] dtc: Provide libfdt

2019-08-05 Thread Andrew Jeffery 



On Mon, 5 Aug 2019, at 16:13, Adrian Bunk wrote:
> On Mon, Aug 05, 2019 at 04:01:57PM +0930, Andrew Jeffery wrote:
> > 
> > 
> > On Mon, 5 Aug 2019, at 14:35, Adrian Bunk wrote:
> > > On Mon, Aug 05, 2019 at 12:42:11PM +0930, Andrew Jeffery wrote:
> > > > Applications are appearing that depend on parsing flattened devicetree
> > > > in userspace on target devices, e.g. pdbg[1]. Mark dtc as providing
> > > > libfdt so application recipes can depend on it.
> > > > 
> > > > [1] https://github.com/open-power/pdbg
> > > 
> > > Shouldn't runtime dependencies on dtc already be autogenerated in this 
> > > case when you have dtc in DEPENDS?
> > 
> > "dtc" doesn't need to appear in depends for pdbg: "dtc-native" does for the
> > purpose of building the devicetrees shipped with the application, but "dtc"
> > doesn't and dtc(1) itself isn't required at runtime, rather we just need 
> > libfdt,
> >...
> 
> How do you link with libfdt without the non-native dtc in DEPENDS?

Currently pdbg includes a copy of libfdt. However, the build system tests for
the presence of a system copy and will prefer it over the included copy.

Andrew
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] dtc: Provide libfdt

2019-08-05 Thread Andrew Jeffery 



On Mon, 5 Aug 2019, at 14:35, Adrian Bunk wrote:
> On Mon, Aug 05, 2019 at 12:42:11PM +0930, Andrew Jeffery wrote:
> > Applications are appearing that depend on parsing flattened devicetree
> > in userspace on target devices, e.g. pdbg[1]. Mark dtc as providing
> > libfdt so application recipes can depend on it.
> > 
> > [1] https://github.com/open-power/pdbg
> 
> Shouldn't runtime dependencies on dtc already be autogenerated in this 
> case when you have dtc in DEPENDS?

"dtc" doesn't need to appear in depends for pdbg: "dtc-native" does for the
purpose of building the devicetrees shipped with the application, but "dtc"
doesn't and dtc(1) itself isn't required at runtime, rather we just need libfdt,
which brings up your point below.

> 
> > Signed-off-by: Andrew Jeffery 
> > ---
> >  meta/recipes-kernel/dtc/dtc.inc | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/meta/recipes-kernel/dtc/dtc.inc 
> > b/meta/recipes-kernel/dtc/dtc.inc
> > index 0650e3c82e6d..d55c8af90660 100644
> > --- a/meta/recipes-kernel/dtc/dtc.inc
> > +++ b/meta/recipes-kernel/dtc/dtc.inc
> > @@ -5,6 +5,8 @@ SECTION = "bootloader"
> >  LICENSE = "GPLv2 | BSD"
> >  DEPENDS = "flex-native bison-native"
> >  
> > +PROVIDES += "libfdt"
> >...
> 
> This should be a proper separate library package, so that applications 
> depending on it stop pulling in the command line tools.

Yeah, you're right, on reflection this was a bit of a hack.

Thanks for the feedback.

Andrew
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] dtc: Provide libfdt

2019-08-04 Thread Andrew Jeffery 
Applications are appearing that depend on parsing flattened devicetree
in userspace on target devices, e.g. pdbg[1]. Mark dtc as providing
libfdt so application recipes can depend on it.

[1] https://github.com/open-power/pdbg

Signed-off-by: Andrew Jeffery 
---
 meta/recipes-kernel/dtc/dtc.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-kernel/dtc/dtc.inc b/meta/recipes-kernel/dtc/dtc.inc
index 0650e3c82e6d..d55c8af90660 100644
--- a/meta/recipes-kernel/dtc/dtc.inc
+++ b/meta/recipes-kernel/dtc/dtc.inc
@@ -5,6 +5,8 @@ SECTION = "bootloader"
 LICENSE = "GPLv2 | BSD"
 DEPENDS = "flex-native bison-native"
 
+PROVIDES += "libfdt"
+
 SRC_URI = "git://git.kernel.org/pub/scm/utils/dtc/dtc.git \
file://make_install.patch \
"
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 0/8] [WIP] runqemu/runqemu-internal: refactor it

2016-05-25 Thread Andrew Jeffery 
On Fri, 2016-05-20 at 10:43 +0800, Robert Yang wrote:
> 
> On 05/20/2016 10:31 AM, Robert Yang wrote:
> > 
> > Hi Nathan,
> > 
> > Thanks, but I'm sorry to say that this is only a RFC, we may change
> > it a lot, I will talk with RP, and let you when we have progresses.
> Oonce we change it a lot, for example, change runqemu to use python
> rather than shell script, your current work based on these patches
> may not work:-(, I will let you know once we have final decisions.

Any word on what direction these patches will take? I'm also looking to
make use of them in the near future, but will hold off if they will
change so significantly.

Cheers,

Andrew

signature.asc
Description: This is a digitally signed message part
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core