Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[several] Ubuntu 24.04 support + various improvements #246

Merged
merged 15 commits into from
Jun 12, 2024

Conversation

SwooshyCueb
Copy link
Member

@SwooshyCueb SwooshyCueb commented May 1, 2024

Addresses #89
Addresses #236
Addresses #237
Addresses #238
Addresses #239
Addresses #240
Addresses #241
Addresses #242
Addresses #243
Addresses #244
Addresses #245
Addresses #248
In service of irods/irods#7592

Companion PRs:

Notes:

  • Ubuntu 24.04 uses GCC 13 and libstdc++ 13 by default.
    In order to build clang 13 against GCC 13 and libstdc++ 13, some patching is needed that is too complex to handle with basic shell commands, so this PR introduces new patching functionality.
    Additionally, a couple of the nlohmann-json tests fail to build. This is fixed upstream by patching the tests themselves. This is fixed in this PR by simply turning off the tests.
  • Testing will be more thorough that would normally be warranted for adding a distro, as this PR patches many externals packages including the compiler and libc++.
  • This PR introduces a python module distro_info.py which is likely to make its way over to the main irods repository soon-ish.

install_prerequisites.py Outdated Show resolved Hide resolved
distro_info.py Outdated Show resolved Hide resolved
patches/nanodbc/1001-add-missing-limits-include.patch Outdated Show resolved Hide resolved
@SwooshyCueb SwooshyCueb force-pushed the noble.main branch 7 times, most recently from 76b5590 to 0ea64b6 Compare May 3, 2024 06:30
@SwooshyCueb SwooshyCueb changed the title [WIP] Ubuntu 24.04 support + various improvements [several] Ubuntu 24.04 support + various improvements May 3, 2024
build.py Outdated Show resolved Hide resolved
distro_info.py Outdated Show resolved Hide resolved
@SwooshyCueb
Copy link
Member Author

Tests are passing! This PR is ready for review.

@korydraughn
Copy link
Contributor

Good stuff. May not be able to look at this until after UGM.

Copy link
Contributor

@alanking alanking left a comment

Choose a reason for hiding this comment

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

Looks great. I just noticed a couple of things in the new module.

Also, would it be good to include some light instructions regarding the patch system? Maybe this is a common thing with which I am unfamiliar, but it seems like it would be good to leave the process for finding / applying patches for posterity. We can also create an issue for adding that to the README (similar to the directions about bumping build number versus bumping build version). Just a thought.

distro_info.py Outdated Show resolved Hide resolved
distro_info.py Outdated Show resolved Hide resolved
distro_info.py Outdated Show resolved Hide resolved
install_prerequisites.py Show resolved Hide resolved
@korydraughn
Copy link
Contributor

Good stuff.

Copy link
Contributor

@alanking alanking left a comment

Choose a reason for hiding this comment

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

Seems good. Please await another approval and I think we're good to # it.

A couple of follow-up questions:

  1. Do we need to release new externals packages before merging the companion PRs?

  2. Had a question about this from OP: "This PR introduces a python module distro_info.py which is likely to make its way over to the main irods repository soon-ish." How do we feel about maintaining a PyPi package? Is that too much? Just thinking ahead to the duplicate code question... (one here, one in main repo)

Neither of these questions are blockers for merging, but just figured I'd put them here.

@SwooshyCueb
Copy link
Member Author

SwooshyCueb commented Jun 11, 2024

  1. Do we need to release new externals packages before merging the companion PRs?

Only the ones that are still drafts.

  1. Had a question about this from OP: "This PR introduces a python module distro_info.py which is likely to make its way over to the main irods repository soon-ish." How do we feel about maintaining a PyPi package? Is that too much? Just thinking ahead to the duplicate code question... (one here, one in main repo)

I don't think that's a solution. If everything goes to plan, it's going to be a development (and possibly runtime) dependency of irods. Therefore, if it's not part of the repository, it has to be installable from a package we can declare a dependency on. We can't declare dependencies on PyPi packages, which is why we have the special handling for pyodbc on centos 7.

@korydraughn
Copy link
Contributor

Is there a possibility for a patch to result in a successful build of externals, but break something within the iRODS server?

Yes. That's why I did so many runs of the test suite.

Did your testing involve all platforms supported by iRODS? My guess is yes due to the nature of the PR. What about plugins?

If there turns out to be an issue caused by a patch, how do you imagine we address them? Have you considered that?

@SwooshyCueb
Copy link
Member Author

Did your testing involve all platforms supported by iRODS? My guess is yes due to the nature of the PR. What about plugins?

I did not run the test suite on any other platforms, nor did I run any plugin test suites. I did, however, ensure that everything still built on all platforms.

If there turns out to be an issue caused by a patch, how do you imagine we address them? Have you considered that?

Depending on the situation, more than likely one of the following:

  • Remove the patch
  • Replace the patch
  • Fix the patch
  • Add another patch (this one might seem weird, but for externally-sourced patches, it can be the right move)

A new externals package would need to be published with the updated patch set.

@alanking
Copy link
Contributor

A new externals package would need to be published with the updated patch set.

And for cases where the patch is fixing a broken external, I imagine this would be a package_revision bump rather than a consortium_build_number bump so that the broken package(s) would be replaced. Does that seem right?

@SwooshyCueb
Copy link
Member Author

A new externals package would need to be published with the updated patch set.

And for cases where the patch is fixing a broken external, I imagine this would be a package_revision bump rather than a consortium_build_number bump so that the broken package(s) would be replaced. Does that seem right?

Generally speaking, yes

Copy link
Contributor

@korydraughn korydraughn left a comment

Choose a reason for hiding this comment

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

If you're happy with changes, squash to taste. No pounds.

@SwooshyCueb
Copy link
Member Author

I wasn't planning on squashing any more than I already have

Copy link
Contributor

@korydraughn korydraughn left a comment

Choose a reason for hiding this comment

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

Pound it.

@SwooshyCueb
Copy link
Member Author

#'d

@alanking alanking merged commit 0040b5e into irods:main Jun 12, 2024
1 check failed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants