-
Notifications
You must be signed in to change notification settings - Fork 224
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
rpms do not build (tested on openSUSE Tumbleweed & Rocky 8.10/9.4) #199
Comments
A quick update: I have been butchering the spec file a bit to at least get an rpm out of the code... -> Specifically for openSUSE, it is possible to see how the files are built in the openSUSE build service and to also build versions locally.
|
So, I have been butchering the spec file in a fork of the repo and I get to build rpm files now... This is a patch file for the .spec file for the configuration I got to... Maybe this could be used to update the spec file? - Given that it does not build rpms as is, building some may be a step forward? @tytso |
Thanks! Did you test this on both Rocky and Tumbleweed? And was this with the unmodified upstream e2fsprogs or one with some of the Lustre's out-of-tree patches (which as I recall had a few lustre-specific binaries added?). What I've been thinking about doing is moving the spec file into contrib, with specific spec files for Fedora, RhEL, SLES, Tumbleweed, etc., since in the past I believe that creating a spec file that works on all RPM-based distros can be challenging. Thsi is especially true if we want to make sure that the generated RPM package is a drop-in replacement for the e2fsprogs RPM built by the distro, both in terms of any distro-specific patches that may have been applied, or distros-ecific pathnamaes which might be different. |
Short answer: Building on Tumbleweed - using the original source, comparing file paths in openSUSE & Rocky rpms to update the spec file. Now for the longer answer: For me, the ideal place to improve things is "upstream". Invariably there will be some distro-specific tweaks (just thinking of the hardening patches in SUSE, whatever they do...) - So I started with the original e2fsprogs code from your repository. My first objective was to make the spec file work - somehow. What complicated matters a little bit, is that the distributions have broken down the whole project into individual rpms, which means looking into the individual rpms and figuring our which binary/library/header goes where... There are also a number of binaries and libraries that I haven't found a home for yet (in the exclude list). With respect to building and distro specific configurations: In this respect, moving the spec file to a dedicated directory with version specific adjustments could be a good idea. And what I learnt of the rpmbuild process is that effectively all it seems to do is pack the binaries and headers into an (rpm) archive from a predefined buildroot where it is installed using |
I guess in a way this is a repeat of bug #33 - maybe there is a way to find a solution?
Context:
We have a lustre file system at work (set up and running).
For tests and experimentation (also preparing future updates) we want to experiment with lustre as well as build our own packages.
The binary path of
make
,make install
seems to work perfectly fine. However one doesn't necessarily want to build lustre from source on all machines, thus building rpms is of interest. (Weirdly enough this randomly worked once on one VM... I don't have it any more though...)Hence I'm interested in the
make rpm
option which presents a headache, as the rpm fails to build...While I started in the Whamcloud fork of e2fsprogs, I replicated this with the code from the git repo here. If a fix can be found (which may also potentially just be better instructions), I believe it should ideally be in the upstream repository.
(It is also my understanding that there aren't huge differences between the patched e2fsprogs for lutre and the normal one.)
openSUSE is my personal choice, Rocky linux is a necessity as the lustre server requires it (at least in all formally supported forms).
The build and errors are/can be obtained in a kvm virtual machine, so they should be readily reproducible.
So, what did I do, what did I get:
The starting position is a default build, then some tweaks:
openSUSE Tumbleweed (up to date as of 2024_10_16)
-> all good after fullcheck
mke rpm:
So, lets build some extra libraries (as the binaries aren't built):
./configure --enable-libuuid --enable-libblkid --enable-fsck --enable-verbose-makecmds
make -j
-> good,make rpm
:???
-> checking in
misc
the binary blkid was built... (But not findfs it seems).Also, despite requesting a build of the libraries, the libraries are missing? But the archives seem to be built when looking in the directories... (
libblkid.a
for example)Rocky 8.10
-> rename test to _m_rootdir_acl to skip it, tests now pass.
make rpm
Rocky 9.4
-> rename test to _m_rootdir_acl to skip it, tests now pass.
make rpm
Conclusion:
As it stands, I think that either the
make rpm
command is bugged (not sure where and how) or I am missing something with respect to building the rpm files and the readme would benefit from updates that clarify how they can/are built.The text was updated successfully, but these errors were encountered: