can't add a second kojibuilder host,
by dust
i have installed kojihub, kojibuilder, kojira on my koji server(hostname is 186), and regen-repo successed.
$ koji regen-gen dist-fc10-build
//task return complete
now i want add a second kojibuilder(hostname is 188), but regen-repo failed.
$ koji list-hosts --channel=createrepo
Hostname Enb Rdy Load/Cap Arches Last Update
kojibuilder1 Y Y 0.0/16.0 i386 2010-01-20 18:05:21
kojibuilder2 Y Y 0.0/16.0 i386 2010-01-20 18:05:20
$ koji regen-host dist-fc10-build
//task return failed.
search /var/log/kojid.log
---
[WARNING] koji.build.TaskManager: Repo directory missing: /mnt/koji/repos/dist-fc10-build/7
---
can anybody help me how to fix the failed.
13 years, 10 months
Does the mash in koji build system support deltamash
by peng chen
Everytime my doing a mash, it takes long time. I think that the process of
make a completely new mash wastes time .
so if the mash can support deltamash, which update the rpm and its repo , it
can save much time, especaily only a few
package have been udpated.
13 years, 10 months
"BuildError: Unknown origin" errors on private koji builders?
by Fleming, Michael
Hello,
I've set up a new Koji 1.3 build hub/builder set (hosted on a clean CentOS 5.4 server) using the Koji Howto from http://fedoraproject.org/wiki/Koji/ServerHowTo (and the ExternalRepoServerBootstrap page, as we have local mrepo-generated mirrors of CentOS 5 / EPEL within our network)
I've followed the instructions closely and it all looks good - the web frontend is fine, koji CLI users are all good, kojira is generating newrepo/regen-repo tasks without issues and my koji builder (initially the same host) is running fine. I've tagged a local -build tag and parent (dist-el5-mycompany-build dist-el5-mycompany respectively), created a build and srpm-build group for the tag (using EPEL's group package list as a base for the minimal buildroot) - it all looks kosher as best I can see.
However all of my koji initiated package builds are failing with the following error:
BuildError: Unknown origin for setup-2.5.58-7.el5.noarch: <url of my local mirror>
The root.log pulls the yum data + packages down and appears to install them fine, then just dies (with the above error message part in the notification email as well as kojid.log.)
I'm stumped regarding where it's gone amiss - any ideas / assistance appreciated :-)
Cheers,
Michael Fleming.
13 years, 10 months
Problem Checking Out
by Eli Wapniarski
Hi
Even after getting a new certificate, running ssh-add. I get the following
error after trying to checkout my package with fedora-cvs:
Permission denied (publickey).
cvs [checkout aborted]: end of file from server (consult above messages if any)
Have I done something wrong? Has some procedure changed?
Any assistance would be greatly appreciated.
Eli Wapniarski
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
13 years, 10 months
[PATCH 1/1] Mash: Either the latest in a tag, or all
by Jeroen van Meeuwen
Hi there,
this patch provides the capability to configure whether only the latest
build of a package tagged with <tag> should be included in the mash, or
whether all builds of a package tagged with <tag> should be included (and
thus be available in the repository).
-- Jeroen
13 years, 11 months
[PATCH 1/1] Mash: Either the latest in a tag, or all
by Jeroen van Meeuwen
Hi there,
this patch provides the capability to configure whether only the latest
build of a package tagged with <tag> should be included in the mash, or
whether all builds of a package tagged with <tag> should be included (and
thus be available in the repository).
-- Jeroen
13 years, 11 months
sign_unsigned.py with custom koji path
by Dan Horák
Hello,
I am running private Koji with /opt/koji path instead of the
default /mnt/koji. But the sign_unsigned.py script from Fedora
Infrastructure has no way to change the path, because it uses
koji.pathinfo object that is preinitialized with /mnt/koji. The attached
patch makes the path settable by the user.
With regards,
Dan
13 years, 11 months
How to handel spinning when i686 versions of packages don't make it into the updates repo?
by William F. Acker WB2FLW +1 303 722 7209
Hi all,
I've always noticed that when a package is updated, sometimes the
i686 version isn't put into the x86_64 repo for updates. As a workaround,
I add the packages to the exclude list in the fedora repo so I don't get
x86_64 versions that are newer than the left behind i686 versions. This
means that my disks will have less i686 stuff than was released originally
by The Fedora Project. I could just carry the updated packages in a local
repo, thereby preserving the original package list. Does anyone know
which is the best approach?
TIA.
--
Bill in Denver
13 years, 11 months
