We are now the only consumer of the svrcore project. To simplify our build and source trees, we should roll this into the ds source tree.
We can continue to produce a seperate svrcore rpm from this, but just built from the ds source tree.
Likely we would ship 389-ds-svrcore which obsoletes the svrcore rpms set.
Metadata Update from @firstyear: - Custom field component adjusted to None - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Custom field type adjusted to None - Custom field version adjusted to None - Issue set to the milestone: 1.4 backlog
https://pagure.io/389-ds-base/pull-request/49589
Metadata Update from @firstyear: - Custom field reviewstatus adjusted to review (was: None)
The Makefile changes merged from the PR are breaking the builds on F28.
@mhonek Said he wainted to look at this (there is another ticket open), but if this is urgent I can look today.
I need to a upstream build of 1.4.0 soon, so this should get fixed by the end of next week.
Still having a lot of problems around this. I know we need to add the following code
makefile.am @@ -1165,6 +1165,7 @@ libsvrcore_la_SOURCES = \ libsvrcore_la_LDFLAGS = $(AM_LDFLAGS) libsvrcore_la_CPPFLAGS = $(AM_CPPFLAGS) $(SVRCORE_INCLUDES) $(DSPLUGIN_CPPFLAGS) +libsvrcore_la_LIBADD = $(NSS_LINK) $(NSPR_LINK)
Even with this we can not build DS upstream do to complaints about libldaputil.la not being found. So right now we can not build master branch on F28 or F29, but I guess that's another issue
Metadata Update from @mreynolds: - Issue assigned to mhonek
As per https://pagure.io/389-ds-base/issue/49552#comment-504253 building on F28+ works. Also, the actual svrcore seems to work just fine. Closing as fixed.
Metadata Update from @mhonek: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Great, thank you @mhonek Sorry to cause so much grief :(
Reopening, looks like there are rpm issues on F28
results: - arch: x86_64 checkname: dist.rpmdeplint item: 389-ds-base-1.4.0.7-1.fc28 outcome: FAILED scenario: x86_64 type: koji_build
package 389-ds-base-devel-1.4.0.7-1.fc28.x86_64 requires libsvrcore.so.0()(64bit), but none of the providers can be installed.
This needs to be investigated...
Metadata Update from @mreynolds: - Issue status updated to: Open (was: Closed)
Upgrades also do not work:
root@hp-dl360g5-01 rpms]# rpm -iUvh * error: Failed dependencies: svrcore conflicts with 389-ds-base-devel-1.4.0.7-1.fc28.x86_64 svrcore = 4.1.3-4.fc28 is needed by (installed) svrcore-devel-4.1.3-4.fc28.x86_64 svrcore conflicts with 389-ds-base-libs-1.4.0.7-1.fc28.x86_64 krb5-server is needed by python3-lib389-1.4.0.7-1.fc28.noarch krb5-workstation is needed by python3-lib389-1.4.0.7-1.fc28.noarch python3-pytest is needed by python3-lib389-1.4.0.7-1.fc28.noarch Updating / installing... 1:389-ds-base-1.4.0.7-1.fc28 ################################# [100%] error: unpacking of archive failed: cpio: Archive file not in header error: 389-ds-base-1.4.0.7-1.fc28.src.rpm cannot be installed
Got it working, just need to run some lib389 tests before sending out for review...
@mreynolds Seems everything is running smoothly now regarding the merged svrcore. Are we good to close this issue?
Yes, closing it out...
Metadata Update from @mreynolds: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2428
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.