Hello, I've just discovered a rather strange glitch with koji, used for internal builds.
I've set it up by following the wiki instructions, and it seems to work pretty well, but I've found out a strange behaviour.
I've set up a build tag (something like myproject-build) for arch x86_64 only, and I've added some externals repo to it (notably centos-x86_64-updates and centos-x86_64-os).
Centos/RHEL (not sure about Fedora) does something tricky BTW: on 64 bit systems, some packages (notably glibc and other low-level system packages) are installed for both supported archs (x86_64 and i386). But the koji "merged" repository xml only includes x86_64 packages; this is a problem when trying to build some packages explicitly relying on the presence of such i386 version.
Also, I sometimes use the koji repo on testing machines to fetch the latest version of my development packages along with os deps. Even tough mash is probably the best tool for such job, it was quite useful, but this is impossible when glibc updates happen -> trying to upgrade the 64 bit glibc version but retaining the old version for 32 bit generates a rpm conflict.
Any clue? Is such behaviour intentional?
Thanks in advance.
On 05/26/2010 10:10 AM, Alan Franzoni wrote:
Hello, I've just discovered a rather strange glitch with koji, used for internal builds.
I've set it up by following the wiki instructions, and it seems to work pretty well, but I've found out a strange behaviour.
I've set up a build tag (something like myproject-build) for arch x86_64 only, and I've added some externals repo to it (notably centos-x86_64-updates and centos-x86_64-os).
Centos/RHEL (not sure about Fedora) does something tricky BTW: on 64 bit systems, some packages (notably glibc and other low-level system packages) are installed for both supported archs (x86_64 and i386). But the koji "merged" repository xml only includes x86_64 packages; this is a problem when trying to build some packages explicitly relying on the presence of such i386 version.
The "mergerepos" tool used by Koji explicitly filters out packages of other arches. So regardless of what the external repos contain, the merged Koji repo will contain only x86_64 and noarch packages. Koji does not support building in a multilib environment.
In order to build 64-bit packages that require 32-bit libs, a special "glibc32" package is used in Fedora Koji.
http://koji.fedoraproject.org/koji/buildinfo?buildID=153452
This is a 64-bit package, but contains 32-bit headers/libs for compiling/linking against. You may be able to reuse this in your Koji environment.
Also, I sometimes use the koji repo on testing machines to fetch the latest version of my development packages along with os deps. Even tough mash is probably the best tool for such job, it was quite useful, but this is impossible when glibc updates happen -> trying to upgrade the 64 bit glibc version but retaining the old version for 32 bit generates a rpm conflict.
Any clue? Is such behaviour intentional?
It is intentional. Koji always builds in a single-arch environment. Any multilib setup needs to be done after the build, when assembling a repo or distro. This is what mash is for.
On 5/26/10 4:31 PM, Mike Bonnet wrote:
It is intentional. Koji always builds in a single-arch environment. Any multilib setup needs to be done after the build, when assembling a repo or distro. This is what mash is for.
A maybe-stupid question would be: is there any way to trigger a mash run for a mash configruation whenever certain conditions (e.g. new package was successfully built) happen? I've found nothing best than a cron script by now, but it's a bit clumsy.
On Wed, 2010-05-26 at 16:55 +0200, Alan Franzoni wrote:
On 5/26/10 4:31 PM, Mike Bonnet wrote:
It is intentional. Koji always builds in a single-arch environment. Any multilib setup needs to be done after the build, when assembling a repo or distro. This is what mash is for.
A maybe-stupid question would be: is there any way to trigger a mash run for a mash configruation whenever certain conditions (e.g. new package was successfully built) happen? I've found nothing best than a cron script by now, but it's a bit clumsy.
Koji is growing support to announce events on a message bus, like qpid. What that would allow folks to do is setup an event bus and create a watcher script that watches for specific events like a build being tagged into a particular tag, which could then trigger the mash call.
On Wed, 26 May 2010, Jesse Keating wrote:
On Wed, 2010-05-26 at 16:55 +0200, Alan Franzoni wrote:
On 5/26/10 4:31 PM, Mike Bonnet wrote:
It is intentional. Koji always builds in a single-arch environment. Any multilib setup needs to be done after the build, when assembling a repo or distro. This is what mash is for.
A maybe-stupid question would be: is there any way to trigger a mash run for a mash configruation whenever certain conditions (e.g. new package was successfully built) happen? I've found nothing best than a cron script by now, but it's a bit clumsy.
Koji is growing support to announce events on a message bus, like qpid. What that would allow folks to do is setup an event bus and create a watcher script that watches for specific events like a build being tagged into a particular tag, which could then trigger the mash call.
i've written a mash plugin for Koji and it works well. I guess I could work with notting to get it included into mash itself.
Tuju
buildsys@lists.fedoraproject.org
-
Alan Franzoni -
Jesse Keating -
Juha Tuomala -
Mike Bonnet