Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 20 additions & 7 deletions ansible/playbooks/roles/compatibility_layer/defaults/main.yml
Original file line number Diff line number Diff line change
@@ -1,11 +1,11 @@
# Defaults file for the compatibility layer role.
---
eessi_version: "2021.12"
eessi_version: "2022.11"

custom_overlays:
- name: eessi
source: git
url: https://github.com/EESSI/gentoo-overlay.git
url: https://github.com/trz42/gentoo-overlay.git
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just pointing this out, so we don't forget to revert this back to EESSI after EESSI/gentoo-overlay#84 is merged...

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@trz42 How do you deal with the branch aspect? Or did you just merge the eessi-2022.11 branch you used for EESSI/gentoo-overlay#84 into your main branch?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To answer my own question: yes, you've just updated the main branch in your fork with EESSI/gentoo-overlay#84, OK.

eclass-overrides: true

cvmfs_start_transaction: false
Expand All @@ -19,18 +19,30 @@ gentoo_prefix_path: /cvmfs/{{ cvmfs_repository }}/versions/{{ eessi_version }}/c
gentoo_git_repo: https://github.com/gentoo/gentoo.git
# Select a specific commit in the gentoo_git_repo that should be used for the bootstrap,
# e.g. by checking: https://github.com/gentoo/gentoo/commits/master
gentoo_git_commit: 7eaa2512d1e6ddb44e3b41bbddf6c74723f234ce
# 2021.12
# gentoo_git_commit: 7eaa2512d1e6ddb44e3b41bbddf6c74723f234ce
# 2022.10 (Oct 11 2022) actually used
# gentoo_git_commit: 3e6e7da40a59134ab2afee9b27b5b0c2051f21a4
# 2022.11 (Oct 28 2022) first try
# this installs gcc-10.4.1_p20221006 in bootstrap stage2/3
# subsequently 10.4.0 cannot be set as default gcc (via gcc-config)
# trying to set 10.4.1_p20221006 fails
# we mask sys-devel/gcc below to not install anything newer than 10.4.0
# gentoo_git_commit: c2d8ce0e1b6206a225a9f2547bbc65c79218756c
# 2022.11 (Nov 3 2022) second iteration made for PR
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@trz42 I'm not sure we should keep this whole history, but the problems with the patched 10.4.1 versions would be good to highlight somehow. I think sticking to 10.4.0 makes sense.

The 10.4.1 versions are test builds I think... Maybe @amadio can clarify?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can prune the comments. For me they add some context right now while we got going again. If we update more frequently or even build compat layers with a bot, they might not provide much useful context or there are other ways to document the history.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pruned some comments.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GCC ebuilds with _p in the version are versions of GCC with extra patches by Gentoo, usually to solve bugs, so you can consider them similar to the other versions. For example sys-devel/gcc-13.0.0_pre20221030 was added to fix https://bugs.gentoo.org/879049. Also, the only reason that GCC 10.x is used for bootstrapping is because GCC 11 requires C++11 to build, and that itself requires a new enough compiler that may not be available on old systems. You don't have to stick to older versions of GCC in EESSI. You can just leave the masks free and choose GCC by adding a slotted version to your set, like sys-devel/gcc:11 if you want GCC 11.x but don't care which minor version. It's quite safe to keep it updated within the same major version (i.e. that won't break packages built on top of the compat layer).

gentoo_git_commit: cec3214ef5d5661e28c9d2c5b5750b27c27c5435
prefix_required_space: 15 GB
prefix_default_gcc: 9.4.0
# version increased to meet requirement of bootstrap procedure
prefix_default_gcc: 10.4.0
prefix_user_defined_trusted_dirs:
- "/cvmfs/{{ cvmfs_repository }}/host_injections/{{ eessi_version }}/compat/{{ eessi_host_os }}/{{ eessi_host_arch }}/lib"
prefix_mask_packages: |
# avoid glibc 2.34, as it's causing issues with the bootstrap, and it's not compatible with CUDA 11.
# see https://github.com/EESSI/compatibility-layer/issues/137 + https://bugs.gentoo.org/824482
>=sys-libs/glibc-2.34
# stick to GCC 9.x; using a too recent compiler in the compat layer complicates stuff in the software layer,
# stick to GCC 10.4.0; using a too recent compiler in the compat layer complicates stuff in the software layer,
# see for example https://github.com/EESSI/software-layer/issues/151
>=sys-devel/gcc-10
>=sys-devel/gcc-10.4.1
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment above should be updated accordingly?
But maybe keep the pointer to EESSI/software-layer#151 since that can help explain why we prefer sticking to an older GCC version.

@trz42 Did you try to build GCC/9.3.0 on top of this compat layer with GCC 10.x as system compiler?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch about the comment. We should keep the pointer yes.

Yes, I've built GCC/9.3.0 and also then software. See trz42/software-layer#42

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated comment.

# avoid libgcrypt 1.9.4 due to compiler errros on ppc64le,
# see https://github.com/EESSI/compatibility-layer/issues/134 + https://bugs.gentoo.org/825722
=dev-libs/libgcrypt-1.9.4
Expand All @@ -41,7 +53,8 @@ prefix_use_builtin_bootstrap: false
prefix_custom_bootstrap_script:
local: "{{ playbook_dir }}/../../bootstrap-prefix.sh"
remote: /tmp/bootstrap-prefix.sh
prefix_singularity_command: "singularity exec -B {{ gentoo_prefix_path }}:{{ gentoo_prefix_path }}"
# the bootstrap script stops if LD_LIBRARY_PATH is set, hence we explicitly unset it
prefix_singularity_command: "singularity exec --env LD_LIBRARY_PATH= -B {{ gentoo_prefix_path }}:{{ gentoo_prefix_path }}"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@trz42 We should add a comment above this line to clarify why LD_LIBRARY_PATH is explicitly set to empty?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because otherwise the bootstrap script simply stops running. It's explained in the PR.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a comment.

prefix_source: "docker://ghcr.io/eessi/bootstrap-prefix:centos8"
prefix_source_options: "{{ gentoo_prefix_path }} noninteractive"
prefix_install: >-
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -20,13 +20,13 @@
creates: "{{ gentoo_prefix_path }}/usr/bin/equery"

- name: Install eselect-repository
portage:
community.general.portage:
package: eselect-repository
state: present

# We need git in order to add Gentoo overlays hosted on git repositories.
- name: Install git
portage:
community.general.portage:
package: dev-vcs/git
state: present

Expand All @@ -53,7 +53,7 @@
}}

- name: Sync the repositories
portage:
community.general.portage:
sync: 'yes'

- name: Find all files and directories in the etc/portage directory of the overlay
Expand Down
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
# Install a specified list of sets and packages.
---
- name: Install package set {{ package_sets }}
portage:
community.general.portage:
package: "@{{ item }}"
state: present
with_items: "{{ package_sets }}"
Expand All @@ -10,7 +10,7 @@
- set

- name: Install additional packages
portage:
community.general.portage:
package: "{{ item }}"
state: present
with_items: "{{ prefix_packages }}"
Expand All @@ -28,4 +28,7 @@
group: "{{ username_on_host.stdout }}"
path: "{{ gentoo_prefix_path }}"
recurse: true
become: false
# task need to be run as root or file ownership cannot be changed
become: true
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also here we should clarify why true (or false is needed, this become bit is a bit cryptic I think...

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the ansible script is run as a normal user, it cannot change ownership of files it doesn't own. That's the purpose of the task ... to change ownership to the user running the task.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a comment.

# original value
# become: false
21 changes: 14 additions & 7 deletions ansible/playbooks/roles/compatibility_layer/tasks/main.yml
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,8 @@
path: "{{ gentoo_prefix_path }}/startprefix"
register: startprefix

- include_tasks: install_prefix.yml
- name: Include task install_prefix.yml
ansible.builtin.include_tasks: install_prefix.yml
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this was changed for a similar reason as community.general.portage above?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was changed to make the sensible-linter happy.

when: not startprefix.stat.exists

- name: Start transaction
Expand All @@ -26,20 +27,26 @@

- name: Make customizations to our Prefix installation
block:
- include_tasks: prefix_configuration.yml
- name: Include task prefix_configuration.yml
ansible.builtin.include_tasks: prefix_configuration.yml

- include_tasks: add_overlay.yml
- name: Include task add_overlay.yml
ansible.builtin.include_tasks: add_overlay.yml
args:
apply:
become: false

- include_tasks: set_glibc_trusted_dirs.yml
- name: Include task set_glibc_trusted_dirs.yml
ansible.builtin.include_tasks: set_glibc_trusted_dirs.yml

- include_tasks: install_packages.yml
- name: Include task install_packages.yml
ansible.builtin.include_tasks: install_packages.yml

- include_tasks: create_host_symlinks.yml
- name: Include task create_host_symlinks.yml
ansible.builtin.include_tasks: create_host_symlinks.yml

- include_tasks: test.yml
- name: Include task test.yml
ansible.builtin.include_tasks: test.yml
tags:
- test

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@
when: eessi_host_os == "linux"

- name: (Re)install glibc with the user-defined-trusted-dirs option
portage:
community.general.portage:
package: sys-libs/glibc
noreplace: false
oneshot: true
Expand Down
Loading