Project

General

Profile

Actions

Bug #42448

closed

test/{fs,cephfs}: Get libcephfs and cephfs to compile with FreeBSD

Added by Willem Jan Withagen over 4 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Target version:
-
% Done:

0%

Source:
Tags:
Backport:
nautilus
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

FreeBSD does not have features.h
FreeBSD dirent{} does not have d_off, so set the offset pointer to 0
FreeBSD does not have sys/xattr.h
But only the XATTR_CREATE define looks to be missing


Related issues 1 (0 open1 closed)

Copied to rgw - Backport #42460: nautilus: test/{fs,cephfs}: Get libcephfs and cephfs to compile with FreeBSDResolvedWillem Jan WithagenActions
Actions #1

Updated by Nathan Cutler over 4 years ago

  • Tracker changed from Backport to Bug
  • Subject changed from test/{fs,cephfs}: Get libcephfs and cephfs to compile with FreeBSD #30505 to test/{fs,cephfs}: Get libcephfs and cephfs to compile with FreeBSD
  • Description updated (diff)
  • Status changed from New to Pending Backport
  • % Done set to 0
  • Backport set to nautilus
  • Regression set to No
  • Severity set to 3 - minor
  • Pull request ID set to 30505

This is fixed in master with https://github.com/ceph/ceph/pull/30505, but only one file does not exist on Nautilus.

src/test/libcephfs/lazyio.cc

But I'm not sure if that allows for easy backporting.
Otherwise I will have to submit a PR directly on Nautilus.

Actions #2

Updated by Nathan Cutler over 4 years ago

  • Copied to Backport #42460: nautilus: test/{fs,cephfs}: Get libcephfs and cephfs to compile with FreeBSD added
Actions #3

Updated by Nathan Cutler over 4 years ago

@Willem A separate nautilus PR is not needed.

You have to cherry-pick the master commits. Whatever relevant "extra" changes are needed for nautilus, you can make at the same time you are resolving the cherry-pick conflicts. Then, describe these changes in the "Conflicts" section along with other modifications you made.

This is not sufficiently covered by SubmittingPatches-backports.rst, unfortunately. I'm working on a new draft, which includes the following:

"Manual changes might be necessary even when a commit cherry-picks cleanly. In this case, a "Conflicts" section should be created manually. Also, when resolving conflicts for a cherry-pick, you might know that additional changes are necessary in stable branch to make the commit work there. In that case, make the changes while resolving the cherry-pick conflicts, and describe these additional changes in the "Conflicts" section.

"Rationale: Though there is a slight semantic difference between conflicts reported by git and "conflicts" that arise due to manual editing after a clean cherry-pick, the Conflicts section is where any and all manual revisions are declared, regardless of what precipitated the need for modification."

Does that make sense?

Actions #4

Updated by Willem Jan Withagen over 4 years ago

Nathan Cutler wrote:

@Willem A separate nautilus PR is not needed.

...............

Does that make sense?

We are going to find out....
Will take a shot at it given the recent new backport instructions and the above.

Actions #5

Updated by Willem Jan Withagen over 4 years ago

Willem Jan Withagen wrote:

Nathan Cutler wrote:

@Willem A separate nautilus PR is not needed.

...............

Does that make sense?

We are going to find out....
Will take a shot at it given the recent new backport instructions and the above.

I think I got it done: #42460

Actions #6

Updated by Nathan Cutler over 4 years ago

  • Status changed from Pending Backport to Resolved

While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved" or "Rejected".

Actions

Also available in: Atom PDF