Learn more about these different git repos.
Other Git URLs
I would like to have support for multilibs in the copr x86_64 repository.
The problem is that I'm testing a build library that is completely relevant for 32bit userspace. (aka mesa-libGL in kwizart/glvnd copr repo). If such support is missing, users will experience a dependency breakage and will not be able to install my copr repo.
That would be very needed in order to better test glvnd enabled mesa until fedora adds support for it.
Since the corp build jobs between x86_64 and i686 seems unrelated (thoses seems to be separate tasks), I expect there is a need to have an option to enable so that a basic multilib support can be computed and the appropriate libraries copied (or better hardlinked) into the x86_64 repository.
I expect that copying ../i386/*-devel and every arched dependencies from the -devel will be enought for a basic multilib support.
Or is there other option ? Thx
Hey, can you please describe the problem in slightly more detail? I have tried installing the mesa-libGL package from kwizart/glvnd copr into both x86_64 and i686 system and the installation went fine in both cases.
@kwizart having multilib support would be neat.
@clime what is needed here is probably: 1. detect that built package is multilib candidate, and if yes: 2. put the results from i386 chroot also into x86_64 result directory
The 1. is tricky, however. The code responsible for multilib detection for Fedora is IMO hard-coded into pungi. Maybe pungi can be "reused" easily, dunno. Maybe we can hack it so there would be python-pungi-libs to serve this purpose for copr?
pungi
Please move to to proper ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1393664
I didn't really mind having this ticket opened here. I think our current Bugzilla could be used for more production instance oriented issues in the future and this issue tracker would serve for bugs and feature requests but we will see. Definitely, the COPR Bugzilla is currently the main one.
I didn't really mind having this ticket opened here.
That has been discussed before, that's why Copr project had intentionally disabled issue tracker on github -- so we are able to track issues at one place. Having two bug-trackers complicates bug reporting a lot -> because you are not sure whether the issue is already reported or not. And that's why there's a link on Copr's frontpage "Report a Bug".
@clime: Most of the multilib logic has moved into python-multilib, but you need to pass it dnf package objects for it to return you useful information.
python-multilib
Thanks. I think I will first do the repo meta-data signing before this ;).
I am not really sure what this issue is about and it wasn't explained, closing. Feel free to reopen.
Metadata Update from @clime: - Issue status updated to: Closed (was: Open)
The point was to allow users to install (some) i386 packages through x86_64 repositories.
Metadata Update from @praiskup: - Issue status updated to: Open (was: Closed)
We discussed this topic again few weeks back, and it is probably enough (at least in the early stages) really to just enable both 32/64 repositories in parallel for the users of multilib repositores.
That said -> if maintainer of copr project explicitly enables multilib support, and both the respective counterpart chroots are enabled and available in that project -> the repo file downloaded by dnf-plugins-core would be slightly modified for the 64bit variant to contain both baseurl's.
I've started here: https://github.com/rpm-software-management/dnf-plugins-core/pull/350
Commit d326a95 fixes this issue
Login to comment on this ticket.