Quick question, would you consider to use mergerepo_c with option
--all  in koji ?
I am happy to work on a patch if it would be accepted. Maybe, we can
keep default behavior and enable with an option on the tag.
My use case is to be able to ship different release built against fix
external repo package that may not be latest version
(Buildrequires:pkg = 1.0.0 while external repo has already 1.1.0)
Include all packages with the same name and arch if version or
release is different. If used --method argument is ignored!
several months ago I talked to dgilmore and probinso and we talked about using DNF in Koji and start building F22
packages using DNF resolver.
The conlusion was that it is quite late in cycle. And it is better to start with plain Mock and leave user to test it on
their local workstatations. Mock is using DNF for fedora-rawhide-* targets for some time already. And I received none
Therefore I'm raising question: Can we switch Koji to use DNF for building rawhide targets?
Of course F22- will still use yum for building.
It would be great if we can make this change before mass rebuils for F23.
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
I have been doing some test for past two days and experimenting with
TmpFS plugin of Mock.
I summarized my findings here:
The performance increase is huge and I believe Koji can do the same.
I.e. enable tmpfs plugin, set the tmpfs size to some big number and
create create big swap - if there is not such big partition available,
it can be done as a file in some data partition.
The code previously would look for a file called extra-footer.html that a koji
admin could override to put some nice extra footer on their koji-web page.
If that file existed, koji-web would read it in verbatim and write it to the
bottom of each served page.
This change enhances that behavior and treats the extra-footer.html file as a
Cheetah template. This way, a koji admin could specify some conditional logic
in the extra-footer file to display this or that thing depending on the dynamic
contents of the page being served.
Note that this is backwards compatible. Static html extra-footer files
already out there in the wild will be interpreted as Cheetah templates and
should be included seamlessly.
www/kojiweb/includes/footer.chtml | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/www/kojiweb/includes/footer.chtml b/www/kojiweb/includes/footer.chtml
index 8dad310..684e5a4 100644
@@ -8,8 +8,7 @@
#set $localfooterpath=$util.themePath("extra-footer.html", local=True)
tl;td: Join at http://lists.rpm.org/mailman/listinfo/rpm-ecosystem if
your interested in any part of the rpm ecosystem.
While there are quite some mailing lists already that deal with the
different tools around and including rpm we realized that there is no
good place to discuss issues that involve multiple parts of (our own)
package handling stack even less so to stay in contact with other rpm
based solutions. To solve this we create a new mailing list:
Normal user questions and development talk is supposed to stay on the
per project mailing lists. The new list is for questions like:
* How do other implementations handle specific problems?
* Is this new feature interesting for downstream distributions?
* How do the different packaging guidelines treat a special topic?
* Anyone there to support our demand for this new rpm feature?
And it is for topics like:
* Packaging guide lines
* RPM features
* Build systems and compose tools
* Dependency solvers, installers and updaters
* RPM based image creation / non rpm based updates for rpm
In short: It is meant to bind the rpm universe together.
Join at http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Please forward this mail to anyone that might be interested - especially
to rpm related sub projects and groups.
Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters