Bug 1643588
Summary: | implement dnf repoquery as a replacement for plain repoquery | |||
---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dalibor Pospíšil <dapospis> | |
Component: | beakerlib | Assignee: | Jakub Heger <jheger> | |
Status: | CLOSED CURRENTRELEASE | QA Contact: | ||
Severity: | high | Docs Contact: | ||
Priority: | high | |||
Version: | rawhide | CC: | dapospis, jheger, mkyral, mvadkert, praiskup | |
Target Milestone: | --- | |||
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | beakerlib-1.18-3 | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1673440 (view as bug list) | Environment: | ||
Last Closed: | 2019-05-24 14:51:14 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: |
Description
Dalibor Pospíšil
2018-10-26 15:40:20 UTC
dnf-utils is not necessary as long as dnf repoquery is used. I will file separate rebase bug. Is there ETA for this to happen? It is blocking Fedora CI for rlFetchSrcForInstalled() call. Seems like `wget` is not installed (by default), and `curl` is underneath used for SRPM downloading, and even though the file doesn't exist -- the 404 placeholder is downloaded. So you can then do: $ cat *.src.rpm <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>404 Not Found</title> </head><body> <h1>Not Found</h1> <p>The requested URL /packages/tar/1.31/4.fc30.pr.00b1c008d5b645cd8edddaa320408ed8/src/tar-1.31-4.fc30.pr.00b1c008d5b645cd8edddaa320408ed8.src.rpm was not found on this server.</p> </body></html> .. following scripting mistakenly expects that if rlFetchSrcForInstalled() did not fail, it is correctly downloaded source RPM. https://jenkins-continuous-infra.apps.ci.centos.org/job/fedora-rawhide-pr-pipeline/813/artifact/package-tests/logs/FAIL_tar-tar-testsuite.log Ah, this is RHEL 8 bug. I'll fill a Fedora one. (In reply to Pavel Raiskup from comment #4) > Ah, this is RHEL 8 bug. I'll fill a Fedora one. I've switched this one. (In reply to Pavel Raiskup from comment #3) > Is there ETA for this to happen? It is blocking Fedora CI for > rlFetchSrcForInstalled() call. Seems like `wget` is not installed (by > default), and `curl` is underneath used for SRPM downloading, and even > though the file doesn't exist -- the 404 placeholder is downloaded. > > So you can then do: > > $ cat *.src.rpm > <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> > <html><head> > <title>404 Not Found</title> > </head><body> > <h1>Not Found</h1> > <p>The requested URL > /packages/tar/1.31/4.fc30.pr.00b1c008d5b645cd8edddaa320408ed8/src/tar-1.31-4. > fc30.pr.00b1c008d5b645cd8edddaa320408ed8.src.rpm was not found on this > server.</p> > </body></html> > > .. following scripting mistakenly expects that if rlFetchSrcForInstalled() > did not fail, it is correctly downloaded source RPM. > > https://jenkins-continuous-infra.apps.ci.centos.org/job/fedora-rawhide-pr- > pipeline/813/artifact/package-tests/logs/FAIL_tar-tar-testsuite.log However this look to me like a separate bug. (In reply to Dalibor Pospíšil from comment #6) > However this look to me like a separate bug. Actually this is probably connected problem. There's no fallback to yumdownloader because curl does not report problem with download of a 404 page. Moreover yumdownloader is not available or at least not prefered. There's a bunch of changes which needs to be done to this area. This should be solved by adding -f option tu curl call. This option causes curl to exit with non-zero code if file is not found. Or by installing wget (against older beakerlib). Both fixes are temporary work-arounds, and I decided a little bit earlier [1]. But the new beakerlib doesn't seem to be using curl, is that so? [1] https://src.fedoraproject.org/tests/tar/c/1899fbe52e9a7d748f61e80dbef9f927622a62ba?branch=master (In reply to Pavel Raiskup from comment #9) > Or by installing wget (against older beakerlib). Both fixes are temporary > work-arounds, and I decided a little bit earlier [1]. But the new beakerlib > doesn't > seem to be using curl, is that so? Beakerlib requires wget or curl, internally it preferres wget if both are available. Should be fixed with this commit https://github.com/beakerlib/beakerlib/commit/fa2cc618949b566dd312794dc15e921dd5ee58a6 Dalibor, could you please review it? |