with multiple repos lorax tries to install multiple versions of same package

[dustymabe]

For Atomic Host we are trying to build media as part of the updates composes. This includes an installer ISO. We hit this problem (example koji task) where lorax tries to install multiple versions of the same package. From the runroot.log:

dnf.exceptions.DepsolveError: 
 Problem 1: cannot install both iwl100-firmware-39.31.5.1-83.fc28.1.noarch and iwl100-firmware-39.31.5.1-85.fc28.1.noarch
  - conflicting requests

NOTE: ignore the fact that the koji task didn't fail, that was a pungi bug

I think this is a problem @bcl already knows about. From this comment He stated: "The NEVRA change was supposed to allow pinning of versions, but it has a problem when an updates repo is included."

[bcl]

This is a DNF bug that has supposedly been fixed upstream. https://bugzilla.redhat.com/show_bug.cgi?id=1548586#c3

[dustymabe]

thanks for the info. I pinged them in the BZ to see if we can get that fixed in f28 to see if it resolves this issue.

[dustymabe]

should this issue be closed ?

[bcl]

should this issue be closed ?

Not yet. AFAIK this is still happening on F28.

[dustymabe]

and I believe it is still an issue in f29

dnf.exceptions.DepsolveError: 
 Problem 1: cannot install both iwl100-firmware-39.31.5.1-88.fc29.noarch and iwl100-firmware-39.31.5.1-87.fc29.noarch
  - conflicting requests

[bcl]

I'm not seeing this with lorax-29.19, dnf-4.0.4-1, libdnf-0.22.0-6 using f29 repo, f29 updates (empty), and f29 updates-testing.

[dustymabe]

@sinnykumari ran a test and this is the failure she saw: loraxrun.txt

I bet she wasn't using the dnf from updates-testing though. @sinnykumari can you update to the versions of rpms mentioned above and see if you have that problem?

[sinnykumari]

I was running lorax earlier on a F28 local machine to build FAH ISO for fedora-29-updates-testing by providing multiple repos. Reason of using F28 host is that our Fedora Koji builders are currently on Fedora 28.

FAH ISO creation on F29 host using lorax works fine. This works with lorax-29.19, dnf-3.5.1-1.fc29.noarch, libdnf-0.19.1-3.fc29.x86_64 and also with dnf-4.0.4-1.fc29.noarch, libdnf-0.22.0-6.fc29.x86_64.

Unfortunately Fedora 28 has dnf-2.7.5-12 latest available and as per dnf bz backporting fixes to 2.7 is not yet planned.

[dustymabe]

so I think the runroot task installs dnf from the f29 repos inside the runroot and then executes lorax so we should be ok? See the runroot log for Fedora-29-updates-testing-20181024.0.

If I'm right we should be fine here and should be able to close this bug.

[sinnykumari]

Yes, installation occurs from F29 repos. But the lorax failure (lorax log ) is at earlier steps "Checking dependencies
" which I think uses host system dnf to resolve dependencies. After dependencies is fulfilled, Downloading F29 packages and other steps takes place.

[dustymabe]

hmm. but lorax isn't even installed on the builder hosts.. it's only installed into the runroot I think. Check out the root.log from the koji task where the rpms get installed into the runroot:

lorax                               x86_64 29.16-1.fc29
dnf                                 noarch 4.0.4-1.fc29

[sinnykumari]

Ah, runroot task runs under mock and my assumption was that lorax runs directly on builders. I was looking at pungi logs from which I didn't realized that it is using mock. We should be good then, sorry about confusion :)

[bcl]

Ok, good. I'm going to add a bunch of lorax tests, starting with the f28-branch, to catch this and other things. Then I'll kludge in a fix for it since it doesn't look like dnf is going to have time.

[dustymabe]

Ok, good. I'm going to add a bunch of lorax tests, starting with the f28-branch, to catch this and other things. Then I'll kludge in a fix for it since it doesn't look like dnf is going to have time.

we technically don't need this in f28 any longer so if you don't need it I wouldn't waste your time.

[bcl]

we technically don't need this in f28 any longer so if you don't need it I wouldn't waste your time.

Thanks, I want to make sure f28 will work with updates repo enabled, and make sure it continues to work :)

[bcl]

PR #514 fixes this.