Hi. I've written up a proposal for a way to support EPEL builds in
Koji. It's not the only way we could do this, but I think it's doable
with a reasonable amount of effort, and has the side-effect of greatly
simplifying the Koji setup process for a lot of people (by removing the
need to bootstrap/import an entire distro of packages into your private
Koji instance). You can view the proposal here:
It's fairly detailed regarding the data model changes necessary, so if
you're not familiar with the Koji codebase you can skip those parts.
Questions and comments welcome.
(refers to koji-1.2.6-1)
Koji seems to have derailed itself and created an unkillable task
Although it has built the rpms, it then seems to have done something odd
to itself because it's entered a failed state but the koji system still
believes that it is still building the package
Result RetryError: unable to retry call 7 (method
host.importChangelog) for session 18591
I've tried koji cancel, and a few of the less savory koji call api
commands but it refuses to accept that the task is dead
I assume that for some reason it's been unable to communicate with the
postgres database but I don't see a means to tell it to retry or just
plain abandon the whole task
>> i'm a novice for system building and have read some articles about
>> pungi and koji recently. but i'm a little confused about the
>> relationship between the tools. in my opinion, pungi is focusing on
>> building iso while koji is focusing on building packages. and i'm
>> wondering if the koji has got some similar functions as pungi does,
>> or is it simply that we use koji to build packages and
>> then make tree/iso by pungi?
> The link that you're looking for is mash.
So, what do they actually work for?
Or in other way, what workflow should we follow when building the distro
with koji and pungi?
i'm a novice for system building and have read some articles about pungi and
koji recently. but i'm a little confused about the relationship between the
tools. in my opinion, pungi is focusing on building iso while koji is
focusing on building packages. and i'm wondering if the koji has got some
similar functions as pungi does, or is it simply that we use koji to
build packages and then make tree/iso by pungi?
I do a large number of local mock builds as a part of the package
reviews that I do, and one problem I consistently run into is
executables and .so files coming out with mode 775, but a scratch
build in Fedora's koji instance showing the expected 755 permissions.
I thought it might be some local environment leaking into my mock
builds, but my personal umask is 022 which should be OK and changing
it doesn't alter the result anyway.
Init'ing a fresh chroot shows the default umask in it is 0002, which
would seem to explain things but wouldn't explain why the Fedora
buildsys has different results. Is there customization done there to
force the umask somehow?
just set up a new koji instance for our internal buildsystem (until
now, we were using mdvsys/mock/createrepo and some control scripts).
i've noticed the use of a Makefile.common in various documentation
"Building with make targets")
i would like to have a look on that. is there any url available ? i've
looked at fedora-packager on fedorahosted but the file is not there.
i'm using right now a subversion instance for storing all the packages
stuff (all sources rpms, sources files (specs, ...) and binary rpms).
the layout it the
one used by MDVSYS perl module.
since i've quite a lot of data in this subversion repo, is there any
chance to reuse the old layout with Koji ? is koji capable of working
with various SCM layout ?