Bug 2283795 - javapackages-tools-6.2.0-11.fc41 (and -9.fc41) FTBFS with RPM 4.20
Summary: javapackages-tools-6.2.0-11.fc41 (and -9.fc41) FTBFS with RPM 4.20
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: javapackages-tools
Version: rawhide
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
Assignee: Mikolaj Izdebski
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F41FTBFS PYTHON3.13 RPM4.20
TreeView+ depends on / blocked
 
Reported: 2024-05-29 11:42 UTC by Miro Hrončok
Modified: 2024-05-31 04:56 UTC (History)
5 users (show)

Fixed In Version: javapackages-tools-6.2.0-12.fc41
Clone Of:
Environment:
Last Closed: 2024-05-31 04:56:21 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Miro Hrončok 2024-05-29 11:42:15 UTC
As visible in Koschei and koji

https://koschei.fedoraproject.org/package/javapackages-tools?collection=f41
https://koji.fedoraproject.org/koji/packageinfo?packageID=13314


javapackages-tools fails to build with a lot of test failures with RPM 4.20.

This happens with both javapackages-tools-6.2.0-11.fc41 and javapackages-tools-6.2.0-9.fc41.


Panu says:

"""
FileNotFoundError: [Errno 2] No such file or directory: 'rpmbuild/BUILD/test_mvn_build_no_args-1/.xmvn/out'
mvn_macros_test.py:275: FileNotFoundError


so yep, that is making assumptions about the build directory layout

probably somewhere in mvn macros
"""

Comment 1 Miro Hrončok 2024-05-29 11:44:21 UTC
Possibly related to https://github.com/rpm-software-management/rpm/issues/2078

Comment 2 Mikolaj Izdebski 2024-05-29 12:08:39 UTC
Confirmed.
Package builds with RPM 4.19, but fails to build with RPM 4.20 due to numerous test failures that indicate reliance on a specific rpmbuild directory layout that was changed in RPM 4.20.
Upstream test suite needs to be adjusted to work with both new and old RPM.

Comment 3 Panu Matilainen 2024-05-29 12:47:57 UTC
I haven't had a chance to look at the involved macros and all, but the short summary of this is that if %{builddir} is defined, then you're building on >= 4.20 in your own private directory and all the build-stuff must happen inside that directory. The traditional %{_builddir} (which could be shared among multiple packages previously) is defined to the same path as %{builddir} for maximum compatibility, but there *are* cases that'll need updating for the new behavior. Like here.

Feel free to ask if you need help / more details.

Comment 4 Mikolaj Izdebski 2024-05-29 14:00:31 UTC
The change in RPM that causes this issue is indeed commit 9d35c8df49 "Introduce an rpm-controlled per-build directory".
After the change rpmbuild cleans the whole _builddir directory, while before it cleaned buildsubdir only.

For example, given this spec file (that doesn't use %setup and thus no buildsubdir):

Name:		foo
Version:	1
Release:	1
Summary:	1
License:	DUMMY
URL:		file:/dev/null
%description
1
%build
touch XXX
%changelog

Running rpmbuild -ba foo.spec
With RPM 4.19 file rpmbuild/BUILD/XXX is present after rpmbuild exits
With RPM 4.20 there is no XXX file nowhere under rpmbuild/BUILD - it gets cleaned up before rpmbuild finishes

From what I can see, builddir cleanup is not configurable by macros.
A possible hack to fix the issue is to define "_fixperms exit 0;"
With this hack file rpmbuild/BUILD/foo-1-build/XXX is present even with RPM 4.20

Comment 5 Miro Hrončok 2024-05-29 14:06:34 UTC
https://github.com/rpm-software-management/rpm/commit/b34333fa021c0ee7215714eeef96d1a2843ea08e removes the builddir. --noclean prevents the deletion.

Comment 6 Mikolaj Izdebski 2024-05-29 14:10:27 UTC
Despite what the commit message says, RPM 4.19 cleans only buildsubdir, not the whole builddir.
In case buildsubdir is not used (like when package does not use %setup/%autosetup), nothing is cleaned.
RPM 4.20 cleans the whole builddir.
I will see if we can use --noclean and if it would help.

Comment 7 Panu Matilainen 2024-05-29 14:13:41 UTC
This failure is *inside* a build, --noclean is only useful for inspecting results *after* rpmbuild completes.
We don't wipe the directory before %check (or that'd be a fun bug).

Comment 8 Mikolaj Izdebski 2024-05-29 14:22:36 UTC
Upstream test suite prepares data (spec, macros), then invokes rpmbuild and after it exits, makes assertions about files under BUILD directory.
It assumes that BUILD directory is not cleaned, but does not pass --noclean.
That test suite is ran as part of %check of another rpmbuild process.

Comment 9 Panu Matilainen 2024-05-29 15:12:50 UTC
Wait, what? It runs rpmbuild from inside rpmbuild?

That's ... unexpected. Poking around a bit, it seems it does -bp, -bi and such steps, and cleanup doesn't run after those. It's just that stuff is at a different path than it was before. I guess I'll have a closer look at this.

Comment 10 Panu Matilainen 2024-05-29 15:46:14 UTC
So AFAICS the tests just make a whole lot of assumptions, like

        File will be copied into 'rpmbuild/SOURCES' and 'rpmbuild/BUILD' by
        default. Path can be absolute or relative to test directory.

I can't test just now but getting it to work under rpm >= 4.20 should be something in the ballpark of:

diff --git a/test/test_rpmbuild.py b/test/test_rpmbuild.py
index eebaece2..558712cb 100644
--- a/test/test_rpmbuild.py
+++ b/test/test_rpmbuild.py
@@ -28,7 +28,7 @@ class Package(object):
         self.__prep = ''
         self.__build = ''
         self.__install = ''
-        self.buildpath = os.path.join('rpmbuild', 'BUILD', name + '-1')
+        self.buildpath = os.path.join('rpmbuild', 'BUILD', name + '-1-build')
         self.__env = dict(os.environ)
         self.__env['HOME'] = os.getcwd()
         self.__env['PATH'] = '{mock}:{path}'.format(mock=DIRPATH,

You can detect the presence of rpm >= 4.20 in various ways, 'rpm --eval "%{?buildroot}"' returning empty is one easy possibility. The proper way to make it work on any rpm would be not using such hardwired paths from the outside and using rpmbuild on its own terms here.

Comment 11 Mikolaj Izdebski 2024-05-31 03:13:14 UTC
Upstream pull request: https://github.com/fedora-java/javapackages/pull/103

Comment 12 Mikolaj Izdebski 2024-05-31 03:20:16 UTC
Downstream pull request: https://src.fedoraproject.org/rpms/javapackages-tools/pull-request/27

Comment 13 Fedora Update System 2024-05-31 03:34:29 UTC
FEDORA-2024-256f3055b3 (javapackages-tools-6.2.0-12.fc41) has been submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-256f3055b3

Comment 14 Fedora Update System 2024-05-31 04:56:21 UTC
FEDORA-2024-256f3055b3 (javapackages-tools-6.2.0-12.fc41) has been pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.