releng

#7739 rubygem-rails occasionally fails to build
Closed: Fixed by kevin. Opened by vondruch.

Closed: Fixed
Reopen Issue
  • Describe the issue
    Koschei builds of rubygem-rails started to fail randomly [1] with errors such as:
DEBUG util.py:522:  Executing command: ['/usr/bin/dnf', 'builddep', '--installroot', '/var/lib/mock/f30-build-13572340-985213/root/', '/var/lib/mock/f30-build-13572340-985213/root//builddir/build/SRPMS/rubygem-railties-5.2.1-2.fc30.src.rpm', '--setopt=tsflags=nocontexts'] with env {'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"', 'PS1': '<mock-chroot> \\s-\\v\\$ ', 'LANG': 'en_US.UTF-8', 'LC_MESSAGES': 'C'} and shell False
DEBUG util.py:439:  Last metadata expiration check: 0:00:01 ago on Thu 30 Aug 2018 04:01:54 PM UTC.
DEBUG util.py:439:  No matching package to install: 'rubygem(bootsnap)'
DEBUG util.py:439:  Not all dependencies satisfied
DEBUG util.py:439:  Error: Some packages could not be found.
DEBUG util.py:577:  Child return code was: 1

This is weird because it sometimes works and it does not work the other time. It seems to be some issues on the builder side.

I initially thought it was a connection issue, but its complaining about same rubygems-bootsnap package, and its not a like a big package to think that it was probably timing out to download the build.

I am still confused on whats going on there.

@kevin Any thoughts?

To me, it looks if some wrong metadata were used or metadata were not downloaded or something like that. Also, I thought that it might be some platform specific issue, e.g. armv7hl does not have the right metadata, but then I rejected this idea for some reason I can't remember now and the removed build logs are not very helpful to analyze such issues.

and the removed build logs

Actually, it is interesting that not all logs for all build are removed. So some machines are treated differently for some reason.

Another instance of the issue:

https://koji.fedoraproject.org/koji/taskinfo?taskID=29535975

Still not resolved:

https://koji.fedoraproject.org/koji/taskinfo?taskID=30750727

rubygem-bootsnap has:

ExcludeArch: armv7hl

The failures you see are form norahc packages buildrequiring rubygem-bootsnap - the randomness here is that noarch packages are built on "random" arch, the failures linked are all from armv7hl builds.

That is a good catch! How I could miss that? So workaround could be to add ExcludeArch: armv7hl into rubygem-rails. Or better to fix rubygem-bootsnap to work on ARM.

Nevertheless, it would be nice if the issue was identified by Koji.

A workaround would be not to use bootsnap when rails is building on ARM (AFAIK it's optional and can be patched out). See the issue(s) linked from bootsnap spec.

As for Koji, I don't think it should be able to detect this kind of things. The builder only has it's own repos - arm in this case.

Going to close this now. If you would like koji to note this better, feel free to file a upstream request for that.

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.