[PATCHSET] Updates for Mageia mock build targets
by Neal Gompa
Hello all,
Since my last email two months ago[1], I've been working steadily
towards the completion of our infrastructure bringup for supporting
COPR oriented workflows. I've added tito and copr CLI tools to the
distribution to enable CLI-centric workflows as well.
While we are still working on bringing up MirrorBrain for metalinks,
we have a rudimentary script that generates a yum-style mirrorlist
that DNF and mock can consume. This has allowed me to update and
expand the Mageia build target configuration for mock, which I have
added to our mock package.
The patches attached to this email update and expand the Mageia
configs, including adding Mageia 6. Note that the Mageia configuration
for armv7hl does not yet work because we are still in the process of
completing the build. We've estimated that it should be finished
within the next couple of days, and then the switch will be flipped to
make it public. This is why the Mageia armv7hl configuration files are
in a separate patch. While I have applied the entire patch series to
the Mageia mock package, it is up to you on whether you wish to
include the armv7hl configuration files or not right now.
These patches should apply cleanly on top of the devel branch for mock.
--
真実はいつも一つ！/ Always, there's only one truth!
7 years, 3 months
- 2
- 2
"Layered" build system
by Avi Kivity
Hello,
I'd like to use koji as a layered build system. I'm not sure that this is the right place, or that koji is the right tool. If not, please let me know what is.
We are building rpms against Fedora and CentOS/RHEL 7. While all our dependencies are in Fedora, that's not the case for RHEL. We would like to store our dependencies (updated rarely) as well as our product packages (updated often) in our local koji, but we'd like the rest of the distribution to be picked up from upstream, rather than having to import (and keep updating) all of our upstream dependencies into our local koji instance.
To make the case concrete, our non-upstream dependencies include gcc 5.3 (included in Fedora 23, but not in RHEL), binutils and isl (dependencies of gcc), boost (we need a later version than is available), ninja-build, ragel, gdb, and pyparsing.
Currently, we just regenerate them each build. Ideally we pull them from our local koji instance.
Avi
7 years, 4 months
- 4
- 5
"Layered" build system
by Avi Kivity
Hello,
I'd like to use koji as a layered build system. I'm not sure that this is the right place, or that koji is the right tool. If not, please let me know what is.
We are building rpms against Fedora and CentOS/RHEL 7. While all our dependencies are in Fedora, that's not the case for RHEL. We would like to store our dependencies (updated rarely) as well as our product packages (updated often) in our local koji, but we'd like the rest of the distribution to be picked up from upstream, rather than having to import (and keep updating) all of our upstream dependencies into our local koji instance.
To make the case concrete, our non-upstream dependencies include gcc 5.3 (included in Fedora 23, but not in RHEL), binutils and isl (dependencies of gcc), boost (we need a later version than is available), ninja-build, ragel, gdb, and pyparsing.
Currently, we just regenerate them each build. Ideally we pull them from our local koji instance.
Avi
7 years, 4 months
- 1
- 0
- ← Newer
- 1
- Older →