https://bugzilla.redhat.com/show_bug.cgi?id=1338928

Is 'https://messinet.com/kojifiles/mirrors/fedora/linux/development/24/Everything/x86_64/os/Packages/b/bash-4.3.42-4.fc24.x86_64.rpm' the correct url for the package in question?

Can you find the logs from the createrepo job that created the repo in question?

Can you share the build tag config?

I have config_opts['package_manager'] = 'dnf' set in /etc/mock/site-defaults.cfg. The Tag Options are related to https://pagure.io/koji/issue/84.

$ koji taginfo f24-build

Tag: f24-build [89]
Arches: i686 x86_64
Groups: build, srpm-build
Tag options:
  mock.plugin_conf.sign_enable : True
  mock.plugin_conf.sign_opts.cmd : 'rpmsign'
  mock.plugin_conf.sign_opts.opts : "--addsign %(rpms)s -D '%%_gpg_name D6E9A911' -D '%%_gpg_path /etc/mock/gnupg-sign'"
This tag is a buildroot for one or more targets
Current repo: repo#8295: 2016-05-24 11:01:44.801356
Targets that build from this tag:
  f24
  f24-candidate
  f24-mss
Inheritance:
  0    .... f24-override [87]
  1    .... f23-build [83]

So, according to mergerepos.log, one of the repos you merged was:
https://messinet.com/kojifiles/mirrors/fedora/linux/development/24/Everything/x86_64/os/

In the root.log, you have the error:
No such file or directory: 'https://messinet.com/kojifiles/mirrors/fedora/linux/development/24/Everything/x86_64/os/Packages/b/bash-4.3.42-4.fc24.x86_64.rpm'

Assuming that you have a standard mirror there, then the download url appears correct.

I'm not sure what is happening here. A few possibilities:

1. dnf in unable to load the url because of access rules and is misrepresenting the error. Can you check your access logs to see if the url was requested/denied? Can you verify that the file is actually there?
2. dnf is somehow misreading the url as a file path. Can you find the section primary.xml in that repo that corresponds to the bash package? In both the merged repo and the original mirror.

On the surface, this does not look like a koji bug. External repos can be tricky.

Replying to #1:
I have checked my access logs, and the file actually gets downloaded, according to Apache. The file is accessible to my builders (and my local LAN) via the URL specified: https://messinet.com/kojifiles/mirrors/fedora/linux/development/24/Everything/x86_64/os/Packages/b/bash-4.3.42-4.fc24.x86_64.rpm'

Replying to #2: I have attached a file with the requested information from each primary.xml

That the file is actually downloaded is even more confusing.

It looks like you are hitting this dnf bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1219638

well, possibly that bug, or related

I think you're exactly right on the RedHat bug. The reason is that if I change my external repositories to use file:///mnt/koji instead of https://messinet.com/kojifiles, DNF works because of the Fedora patch: http://pkgs.fedoraproject.org/cgit/rpms/dnf.git/commit/?h=f23&id=85b88dbcae49712956c869dd27b09fdbf9fa5ec3 which only handles file:// URLs: if path.startswith("file://"):

I'm using http(s):// instead of file:// as I'm hoping for the day that Koji doesn't require NFS-mounted /mnt/koji (we're almost there).

So what do you propose?

When creating a repo by merging some repos, and if one of them is an external repo, then the repo we just created will has some location tags with their 'xml:base' attribute set. And such repo will cause the dnf to be failed when building buildroots.

The dnf team said that they plan to fix the bug --DNF doesn't treat the "xml:base" attribute in the primary.xml location tag correctly--in dnf-2.0, and now on Fedora 24 the dnf is 1.10.1, hence we need have enough patience before the dnf team resolve this issue. Hence I think we probably need a workaround.

It's possible to let the mergerepos cli to convert

<location xml:base="http://host/pat", href="rpm_path">

to

<location href="http://host/path/rpm_path">

But does this way will resolve this issue?

Perhaps we can use the yum-deprecated instead of dnf before the bug be fixed.

@mikem what do you think?

While I don't find an API that let's insert or update a tag extra data, but for these build tags that will be used in Fedora >= 24, we can set following key-value for these tags as their extra data

mock.package_manager = yum-deprecated

Then the mock will use the yum-deprecated as its package_manager, hence we can resolve this issue. At least, this is a possible workaround.

Because of the issue: createTag method should support to set extra data for a tag has been fixed, hence we can insert and update a tag extra data now.

The dnf team said that they plan to fix the bug --DNF doesn't treat the "xml:base" attribute in the primary.xml location tag correctly--in dnf-2.0, and now on Fedora 24 the dnf is 1.10.1, hence we need have enough patience before the dnf team resolve this issue. Hence I think we probably need a workaround.

dnf bug has been fixed in dnf-1.1.10-1.fc24 dnf-1.1.10-1.fc23 dnf-1.1.10-1.fc25

The dnf team said that they plan to fix the bug --DNF doesn't treat the "xml:base" attribute in the primary.xml location tag correctly--in dnf-2.0, and now on Fedora 24 the dnf is 1.10.1, hence we need have enough patience before the dnf team resolve this issue. Hence I think we probably need a workaround.

dnf bug has been fixed in dnf-1.1.10-1.fc24 dnf-1.1.10-1.fc23 dnf-1.1.10-1.fc25

mock.package_manager = yum-deprecated will raise error, only yum or dnf is supported by package_manager -- installed mock is mock-1.3.4-1.fc24.noarch

tested on my local f24 builder:

• dnf-1.1.9-2.fc24.noarch

  The workaround - setting mock.package_manager = yum for tag.extra works fine here;
  dnf bug is not fixed here

• dnf-1.1.10-4.fc24.noarch

  Setting mock.package_manager = yum for tag.extra also works fine here;
  dnf bug is fixed on this version.

So you can fix this issue by
1. upgrade dnf to > dnf-1.1.10-1.fc24 dnf-1.1.10-1.fc23 dnf-1.1.10-1.fc25
2. $koji edit-tag ${tagname} -x mock.package_manager=yum

Close it as fixed. If any further problem, feel free to reopen it.
Thanks