pixi run build failed - fresh ubuntu <strike>22.04</strike>24.04

[pieper]

Tested on fresh ubuntu 22.04 machine.

Installed pixi and podman, both seemed to work.

Ran pixi run build which ran for a long time and then complained about missing python. Installed python 3.12.3 and restarted build. Ran for a long time and then gave this error:

> [email protected] test:buildTestPipelines:emscripten /home/exouser/ITK?
? > node src/itk-wasm-cli.js -i itkwasm/emscripten:latest -b emscripten-build?
? Build environment image not found, pulling itkwasm/emscripten:latest...
? Error: short-name "itkwasm/emscripten:latest" did not resolve to an alias a?
? ?  Could not pull docker image itkwasm/emscripten:latest
? ?ELIFECYCLE? Command failed with exit code 1.
?? Failed in 5.9s at /home/exouser/ITK-Wasm/packages/core/typescript/itk-wasm
/home/exouser/ITK-Wasm/packages/core/typescript/itk-wasm:
?ERR_PNPM_RECURSIVE_RUN_FIRST_FAIL? [email protected] build: `pnpm build:tsc && pnpm build:bundle && pnpm build:minBundle && pnpm build:workerBundle && pnpm build:workerMinBundle && pnpm test:buildTestPipelines:emscripten && pnpm test:bindgenTestPipelines:typescript`
Exit status 1
?ELIFECYCLE? Command failed with exit code 1.

Ran again and it failed in the same place.

[thewtex]

Hi @pieper , thanks for reporting the issues you encountered.

It is unexpected that it would be complaining about a missing python because it should be using the python pixi provides in the .pixi folder.

? Error: short-name "itkwasm/emscripten:latest" did not resolve to an alias a?

This is due to a configuration issue, and maybe we can improve ITK-Wasm's configuration so it just works by default.

To help diagnose the issue, what is the value of unqualified-search-registries in your /etc/containers/registries.conf file?

[pieper]

Hi Matt @thewtex -

Thanks for your help with this. I agree, it will be great to get to a point where this just works.

what is the value of unqualified-search-registries in your /etc/containers/registries.conf file?

There is none. All lines in that file are commented out.

Details

exouser@itkwasm:~$ cat /etc/containers/registries.conf

For more information on this configuration file, see containers-registries.conf(5).

NOTE: RISK OF USING UNQUALIFIED IMAGE NAMES

We recommend always using fully qualified image names including the registry

server (full dns name), namespace, image name, and tag

(e.g., registry.redhat.io/ubi8/ubi:latest). Pulling by digest (i.e.,

quay.io/repository/name@digest) further eliminates the ambiguity of tags.

When using short names, there is always an inherent risk that the image being

pulled could be spoofed. For example, a user wants to pull an image named

foobar from a registry and expects it to come from myregistry.com. If

myregistry.com is not first in the search list, an attacker could place a

different foobar image at a registry earlier in the search list. The user

would accidentally pull and run the attacker's image and code rather than the

intended content. We recommend only adding registries which are completely

trusted (i.e., registries which don't allow unknown or anonymous users to

create accounts with arbitrary names). This will prevent an image from being

spoofed, squatted or otherwise made insecure. If it is necessary to use one

of these registries, it should be added at the end of the list.

# An array of host[:port] registries to try when pulling an unqualified image, in order.

unqualified-search-registries = ["example.com"]

[[registry]]

# The "prefix" field is used to choose the relevant [[registry]] TOML table;

# (only) the TOML table with the longest match for the input image name

# (taking into account namespace/repo/tag/digest separators) is used.

# The prefix can also be of the form: *.example.com for wildcard subdomain

# matching.

# If the prefix field is missing, it defaults to be the same as the "location" field.

prefix = "example.com/foo"

# If true, unencrypted HTTP as well as TLS connections with untrusted

# certificates are allowed.

insecure = false

# If true, pulling images with matching names is forbidden.

blocked = false

# The physical location of the "prefix"-rooted namespace.

# By default, this is equal to "prefix" (in which case "prefix" can be omitted

# and the [[registry]] TOML table can only specify "location").

# Example: Given

# prefix = "example.com/foo"

# location = "internal-registry-for-example.com/bar"

# requests for the image example.com/foo/myimage:latest will actually work with the

# internal-registry-for-example.com/bar/myimage:latest image.

# The location can be empty if prefix is in a

# wildcarded format: "*.example.com". In this case, the input reference will

# be used as-is without any rewrite.

location = internal-registry-for-example.com/bar"

# (Possibly-partial) mirrors for the "prefix"-rooted namespace.

# The mirrors are attempted in the specified order; the first one that can be

# contacted and contains the image will be used (and if none of the mirrors contains the image,

# the primary location specified by the "registry.location" field, or using the unmodified

# user-specified reference, is tried last).

# Each TOML table in the "mirror" array can contain the following fields, with the same semantics

# as if specified in the [[registry]] TOML table directly:

# - location

# - insecure

[[registry.mirror]]

location = "example-mirror-0.local/mirror-for-foo"

[[registry.mirror]]

location = "example-mirror-1.local/mirrors/foo"

insecure = true

# Given the above, a pull of example.com/foo/image:latest will try:

# 1. example-mirror-0.local/mirror-for-foo/image:latest

# 2. example-mirror-1.local/mirrors/foo/image:latest

# 3. internal-registry-for-example.com/bar/image:latest

# in order, and use the first one that exists.

And I'm sorry, I'll edit the title of this issue - the VM is ubuntu 24.04, not 22.04. I'm using a Jetstream2 instance.

Regarding the python issue, we could start again from scratch and find that spot if it would help.

[thewtex]

@pieper Steve, thanks for the information and improving the experience!

Please try out #1285 .

And extra step is documented for getting started quickly -- the steps are now:

./src/docker/pull.sh
pixi run build
pixi run test

Regarding the python issue, we could start again from scratch and find that spot if it would help.

Yes, let's fix that, too, if we can.

[pieper]

Hi @thewtex -
I created a new VM with ubuntu 24.04.
I installed pixi using the one-liner and podman using apt-get.
I did the pull.sh and everything went normally.
Then running pixi run build is taking a very long time with no apparent progress:

After some time is started up and is now running, so I guess this is some kind of error in the progress reporting. I'll check back later to see how it goes.

[pieper]

The build finally timed out, which is odd since Jetstream2 is supposed to be on Internet2, and should be fast and reliable. I'll try again.

[pieper]

The network issue appears to have been transient, so when I ran again I encountered the python issue, so I broke that into a new issue #1289.

[pieper]

The build made it further, but died again. Perhaps it's out of ram. The machine has 30GB and 8 cores, but no swap configured.

packages/core/typescript/create-itk-wasm build$ tsc --pretty
?? Done in 1.9s
packages/core/typescript/itk-wasm build$ pnpm build:tsc && pnpm build:bundle && pnpm build:minBundle && pnpm build:workerBundle && pnpm build:workerMi?
? > [email protected] build:tsc /home/exouser/ITK-Wasm/packages/core/typescript/itk-wasm
? > tsc --pretty
? > [email protected] build:bundle /home/exouser/ITK-Wasm/packages/core/typescript/itk-wasm
? > esbuild --bundle --format=esm --outfile=./dist/bundles/itk-wasm.js ./dist/index.js
?   dist/bundles/itk-wasm.js  138.4kb
? ? Done in 17ms
? > [email protected] build:minBundle /home/exouser/ITK-Wasm/packages/core/typescript/itk-wasm
? > esbuild --minify --bundle --format=esm --outfile=./dist/bundles/itk-wasm.min.js ./dist/index.js
?   dist/bundles/itk-wasm.min.js  59.8kb
? ? Done in 17ms
? > [email protected] build:workerBundle /home/exouser/ITK-Wasm/packages/core/typescript/itk-wasm
? > esbuild --bundle --format=esm --outfile=./dist/pipeline/web-workers/bundles/itk-wasm-pipeline.worker.js ./dist/pipeline/web-workers/itk-wasm-pipel?
?   dist/pipeline/web-workers/bundles/itk-wasm-pipeline.worker.js  151.6kb
? ? Done in 15ms
? > [email protected] build:workerMinBundle /home/exouser/ITK-Wasm/packages/core/typescript/itk-wasm
? > esbuild --minify --bundle --format=esm --outfile=./dist/pipeline/web-workers/bundles/itk-wasm-pipeline.min.worker.js ./dist/pipeline/web-workers/i?
?   dist/pipeline/web-workers/bundles/itk-wasm-pipeline.min.worker.js  89.3kb
? ? Done in 15ms
? > [email protected] test:buildTestPipelines:emscripten /home/exouser/ITK-Wasm/packages/core/typescript/itk-wasm
? > node src/itk-wasm-cli.js -i itkwasm/emscripten:latest -b emscripten-build -s ./test/pipelines build
? ?  Error: runc: runc create failed: unable to start container process: error during container init: error setting cgroup config for procHooks proces?
? ?ELIFECYCLE? Command failed with exit code 1.
?? Failed in 6.4s at /home/exouser/ITK-Wasm/packages/core/typescript/itk-wasm
/home/exouser/ITK-Wasm/packages/core/typescript/itk-wasm:
?ERR_PNPM_RECURSIVE_RUN_FIRST_FAIL? [email protected] build: `pnpm build:tsc && pnpm build:bundle && pnpm build:minBundle && pnpm build:workerBundle && pnpm build:workerMinBundle && pnpm test:buildTestPipelines:emscripten && pnpm test:bindgenTestPipelines:typescript`
Exit status 1
?ELIFECYCLE? Command failed with exit code 1.

[pieper]

Running pixi run build again fails in the same spot, and watching memory doesn't indicate any issues. Also this is the basically same error as reported at the beginning of this issue thread, so there is a real build error.