Comments

22 Comments
karma

False positive. Caused by gating misconfiguration. PR#16 fix that.

User Icon mkolar commented & provided feedback on dwz-0.15-6.fc40 3 months ago
karma

Failure is false positive. It's caused by gating misconfiguration. Please waive it and merge PR#12 to prevent this in the future.

karma

@yselkowitz @wcohen It's stuck due to gating misconfiguration. A failure is a false positive. Please waive it and merge PR#8 to prevent this in the future.

User Icon mkolar commented & provided feedback on gdb-13.2-3.fc37 7 months ago
karma

False positive. The failure in fedora-ci.koji-build.tier0.functional was observed due to an obsoleted gating configuration that was used during the build. See the difference against rawhide:

$ git diff 0db8cdbb151184e86de93c5dfee020c45c89f394 plans
diff --git a/plans/ci.fmf b/plans/ci.fmf
index 1ad2c12..85710d6 100644
--- a/plans/ci.fmf
+++ b/plans/ci.fmf
@@ -3,4 +3,4 @@ discover:
     how: fmf
     directory: tests
 execute:
-    how: beakerlib
+    how: tmt

Testing passed manually.

karma

It's a false positive. The issue is caused by a new rpm build behavior. So the testcase needs to be adapted to the new behavior. @besser82 made a workaround by commits: 1ca25b2, b105e87, e3ad0b0.

The subsequent issue fixed in PR#33, see FEDORA-2023-5e767d7d2b.

karma

It's a false positive. The issue fixed in PR#33.

rpm-4.18.92.tar.bz2 tarball of rpm package contain the guilty code. Older rpm-4.18.91.tar.bz2 doesn't generate mentioned directory:

--- rpm-4.18.91/macros.in   2023-06-09 13:32:52.000000000 +0200
+++ rpm-4.18.92/macros.in    2023-08-01 14:37:23.000000000 +0200
@@ -262,6 +267,9 @@
 #  Build root path, where %install installs the package during build.
 %buildroot   %{_buildrootdir}/%{NAME}-%{VERSION}-%{RELEASE}.%{_arch}

+#  Path for spec file snippets generated during build
+%specpartsdir %{_builddir}/%{buildsubdir}-SPECPARTS
+
 #  Directory where temporaray files can be created.
 %_tmppath    %{_var}/tmp

@@ -752,11 +760,12 @@
   RPM_SOURCE_DIR=\"%{_sourcedir}\"\
   RPM_BUILD_DIR=\"%{_builddir}\"\
   RPM_OPT_FLAGS=\"%{optflags}\"\
+  RPM_LD_FLAGS=\"%{?build_ldflags}\"\
   RPM_ARCH=\"%{_arch}\"\
   RPM_OS=\"%{_os}\"\
   RPM_BUILD_NCPUS=\"%{_smp_build_ncpus}\"\
   RPM_SPECPARTS_DIR=\"%{specpartsdir}\"\
-  export RPM_SOURCE_DIR RPM_BUILD_DIR RPM_OPT_FLAGS RPM_ARCH RPM_OS RPM_BUILD_NCPUS RPM_SPECPARTS_DIR\
+  export RPM_SOURCE_DIR RPM_BUILD_DIR RPM_OPT_FLAGS RPM_ARCH RPM_OS RPM_BUILD_NCPUS RPM_SPECPARTS_DIR RPM_LD_FLAGS\
   RPM_DOC_DIR=\"%{_docdir}\"\
   export RPM_DOC_DIR\
   RPM_PACKAGE_NAME=\"%{NAME}\"\
karma

It's a false positive, manually passed. I can confirm that the failing tests have been fixed.

The issue is caused by a new rpm build behavior. The rpmbuild -bp SPECS/*.spec command for some reason generates two BUILD/boost* directories (boost_1_81_0 and boost_1_81_0_SPECPART). The testcase only expects one directory and that's why command cd /home/boost.HaBUzVqRpH/BUILD/boost* failed with cd: too many arguments.

So the testcase needs to be adapted to the new behavior. Does anyone know where boost_1_81_0_SPECPART came from?

Same issue as in FEDORA-2023-30e7874cdc. Reported 2231976, 2231977.

Same issue as in FEDORA-2023-30e7874cdc. Reported 2231976, 2231977.

it's regression. Passed with boost-1.78.0-11.fc38. Reported 2231976, 2231977.

User Icon mkolar commented & provided feedback on gdb-13.1-4.fc39 a year ago
karma

Manually passed.

User Icon mkolar commented & provided feedback on gdb-12.1-3.fc36 a year ago
karma

failed due to infrastructure issue, fixed by 4896bb0 commit

User Icon mkolar commented & provided feedback on gdb-12.1-10.fc38 a year ago
karma

failed due to infrastructure issue

karma

failed due to infrastructure issue

karma

failed due to infrastructure issue

karma

failed due to infrastructure issue

User Icon mkolar commented & provided feedback on dwz-0.14-4.fc36 a year ago
karma

different gdb behavior. dwz is innocent.

karma

failure is caused by outdated testcase