Hide Forgot
Description of problem: Rpmbuild of above version fails with File not found .../usr/lib64/python3.5/site-packages/__pycache__/uno.cpython-* etc. Version-Release number of selected component (if applicable): libreoffice 5.2.3.3-4 Earlier build of Version 5.2.3.1-1 was good How reproducible: Very Steps to Reproduce: 1. rpmbuild -bb libreoffice.spec 2. wait... (hey - its an energy efficient CPU) 3. "RPM build errors:..." Actual results: No RPM Expected results: Shiny new RPM Additional info: No apparent reason shown for the failure to create the files in question, nor the directory .../site-packages/__pycache__ Nothing related in the %changelog. I have a logfile (61M) I can extract info from if needed, but I cleared out the previous version before I started so can't do a diff. Python updated from 3.5.1-17 to 3.5.2-3 between the builds. If someone has archived the earlier 5.2.3.1-1 I could rerun it.
Well, 5.2.3.3-4 certainly built fine in koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=814722 , with python3 3.5.2-4. The files under __pycache__ are created by python in some post-build rpm macro. So either the earlier python3 revision was broken, or there is something on your system that disables their creation. Note that building on a live system with rpmbuild is inherently unreliable: custom configuration, no control over installed packages, etc. The preferred way is to use mock. Also, may I ask why are you building libreoffice packages for yourself instead of using the distro ones?
(In reply to David Tardon from comment #1) [...] To take your points in reverse order: 3) I wanted to try the latest libreoffice upstream build, but had got sick of manually updating multiple (household) installs of the upstream RPMS, and decided to build the fc25 source against my current fc24 install to forestall failed dependencies. This worked fine for 5.2.3.1-1 and I spread the resulting RPMs the other hosts. The forthcoming fc25 upgrade will eventually catch up with it all. 2) I tend to build on a live system because that is where I want the result, I don't do much of it anyway, and it is usually because I need to satisfy some condition for a package not in the distro I'm building for the live machine. I might finish setting up a mockbuild account, but it has worked fine as is for me for decades. 1) Regarding __pycache__, there is absolutely nothing in the log file to show why it failed. The only thing I can think of is that because /usr/lib64/python3.5/site-packages/__pycache__/unohelper.cpython-35.pyc etc exists on the host from the previous build and install, the scripts failed to generate it anew. There is a hint of bad build scripts from this other error message I didn't mention: chmod: changing permissions of '/home/alland/rpmbuild/BUILDROOT/libreoffice-5.2.3.3-4.fc24.x86_64/usr/lib64/libreoffice/share/autocorr': Operation not permitted This comes about because this is a symlink to /usr/lib64/libreoffice/share/autocorr on the host, installed as part of its older libreoffice packages. A no-no from my perspective. For completeness I should backup this system (I keep the OS partition to 16G so it only takes 10 min) blow away the libreoffice install and start again.
(In reply to Allan Duncan from comment #2) > 3) I wanted to try the latest libreoffice upstream build, but had got sick > of manually updating multiple (household) installs of the upstream RPMS, and > decided to build the fc25 source against my current fc24 install to > forestall failed dependencies. Building of F-25 package on F-24 is not supported. If there is a problem, you are on your own... > > 1) Regarding __pycache__, there is absolutely nothing in the log file to > show why it failed. The only thing I can think of is that because > /usr/lib64/python3.5/site-packages/__pycache__/unohelper.cpython-35.pyc etc > exists on the host from the previous build and install, the scripts failed > to generate it anew. > > There is a hint of bad build scripts from this other error message I didn't > mention: > chmod: changing permissions of > '/home/alland/rpmbuild/BUILDROOT/libreoffice-5.2.3.3-4.fc24.x86_64/usr/lib64/ > libreoffice/share/autocorr': Operation not permitted > > This comes about because this is a symlink to > /usr/lib64/libreoffice/share/autocorr on the host, installed as part of its > older libreoffice packages. > A no-no from my perspective. This is an example of what I wrote: an extraneous (from the point of the build) package influencing the build... Anyway, our primary target are builds using mock/koji. Anything else is optional.