-
Notifications
You must be signed in to change notification settings - Fork 0
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
DAOS-14410 Update to 2.0 #33
Conversation
8957b2d
to
9f9408e
Compare
Signed-off-by: Jan Michalski <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't you want to disable the exclusion of ndctl in this PR similar to what you are doing in #32?
debian/changelog
Outdated
@@ -1,3 +1,9 @@ | |||
pmdk (2.0.0-1) stable; urgency=medium | |||
|
|||
* Upgrade to 2.0.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please expand on the resulting packaging differences this release makes (i.e. the changes to debian/control
and associated files) and why those are needed (i.e. the changes in pmdk-2.0.0 that are causing them).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
pmdk.spec
Outdated
@@ -652,6 +510,9 @@ cp utils/pmdk.magic %{buildroot}%{_datadir}/pmdk/ | |||
|
|||
|
|||
%changelog | |||
* Tue Sep 19 2023 Jan Michalski <[email protected]> - 2.0.0-1 | |||
- Update to release 2.0.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please expand on the resulting packaging differences this release makes (i.e. the changes to the subpackages) and why those are needed (i.e. the changes in pmdk-2.0.0 that are causing them).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
@brianjmurrell as I see from the initial builds of #32, it will be easier to update first to 2.0.0 and then to enable back the ndctl. |
Agreed. Moreover, the update to 2.0 should be relatively easy whereas reinstantiating the NDCTL use has already proven to be challenging. On top of that, I think doing two big changes at once is too risky. 😉 |
…gelogs Signed-off-by: Jan Michalski <[email protected]>
Signed-off-by: Jan Michalski <[email protected]>
Signed-off-by: Jan Michalski <[email protected]>
pmdk.spec
Outdated
BuildRequires: glibc-devel | ||
BuildRequires: autoconf | ||
BuildRequires: automake |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these no longer needed to build pmdk? Did 2.0.0 change configure/build systems? https://github.com/pmem/pmdk/blob/ba92d6b469d52d16f26279bebaf317bbdbb3822c/INSTALL.md?plain=1#L12-L14 seems to indicate that autoconf
is still used.
As for glibc-devel, does pmdk really not use glibc at all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing glibc-devel
is one step too far. 😁
But autoconf
and automake
are not used. Sadly, INSTALL.md
requires cleanup.
pmdk.spec
Outdated
NORPATH=1 \ | ||
BUILD_EXAMPLES=n \ | ||
BUILD_BENCHMARKS=n |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that these are common and being repeated 3 times (and as you can see, having to be updated in 3 different places) it might be good to have these defined in a macro once and then referenced in the 3 places they are needed. Then any future updates of these will only be in the one place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
pmdk.spec
Outdated
- removes all pmem2_async operations (and the miniasync dependency). | ||
- Remove BUILD_RPMEM which was removed in release 1.13 (no change to | ||
the resulting packaging). | ||
- Remove deprecated build requirements. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the removal of the autoconf
(and friends) BuildRequires:
? It's not clear to me that this should be done. Pending your answer on the previous question.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. This is this little cleanup in BuildRequires
. To be clear I just added the list of removed dependencies.
pmdk.spec
Outdated
%if %{without ndctl} | ||
NDCTL_ENABLE=n \ | ||
NDCTL_ENABLE=n | ||
%endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be processed as part of make_common_args
to further DRY this out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
What is the intention of #32 in relation to this PR? |
This PR is about bumping up the PMDK version to the latest 2.0 release. #32 attempts to restore usage of NDCTL which is critical for PMDK to assure correctness of data read from PMem. Both of these are required and orthogonal. #32 has to happen in some form no matter whether we decide to upgrade PMDK or not. Upgrading PMDK is not required to re-enable NDCTL. I think why we need to upgrade PMDK is self-explanatory and unrelated to the NDCTL issue. I do not foresee technical difficulties in landing this PR. Whereas #32 requires solving some technical difficulties as you may recall from DAOS-4183. |
Signed-off-by: Jan Michalski <[email protected]>
But really, if you land this one before #32, you will need to rebase #32 on master again to pick this one up, yes? If #32 is intended to land first though, should the |
Seems to be failing testing though still. Is this expected? |
Signed-off-by: Jan Michalski <[email protected]>
It is true. But I bet @grom72 doesn't mind. Probably #32 should be marked as a draft just not to bother you before it is even ready to be reviewed, am I right @grom72? And this is probably where the confusion comes from. I am not sure what the practice should be in this case.
It is highly improbable. #32 requires first fixes to daos-stack/daos which are far from being ready. |
A funny thing. The latest build combined with this replay constitutes one successful run. @brianjmurrell is it okay or I should further investigate? |
Please add @daos-stack/release-engineering as a reviewer if/when you are ready to land this and have this version of PMDK be what is used on |
No description provided.