Supermin builds very tiny appliances as described here:
http://libguestfs.org/supermin.1.html
To do this, it needs to have access to the original /etc files
[technically, any file marked %config by RPM] since those are the only
files that could be modified by the administrator, so those are the
only ones we need to save in the appliance at build time.
When not running under Koji, it gets these by downloading the RPMs
(using yumdownloader or the dnf equivalent), unpacking them and
extracting the /etc files it needs.
However this doesn't work when running under Koji because there is no
network access and no root access (so we can't just read the
unmodified files from /etc). This is of course as it should be.
Since Koji doesn't provide an official way to get to the pristine RPMs
that were used to build the buildroot, we grabbed them from the yum
cache. But since the move to dnf in Fedora Rawhide, this no longer
works as dnf defaults to keepcache=0 (which is not a great decision
for plenty of other reasons, but dnf upstream show no sign of changing
this despite many asking).
Anyhow, this patch takes the path of least resistance and just
overrides the default so it's the same as it was in yum. It would be
nice to have a way to access pristine build RPMs in Koji/mock, but
that's probably a much larger patch.
Rich.

Hi Kojis,
sometimes I'm searching for new packages on KOJI, for example new
kernels, but I see only a "Finished" column (beside others) on the
specific website. It would be helpful for me if the "Finished" column
could display a little bit more: The time of *starting* the package
generation and the time when the generation has *finished* (with/without
error), so one could guess the remaining time of package generation.
I would be grateful for such an improvement.
Kind regards
Joachim Backes
--
Fedora release 23 (Twenty Three)
Kernel-4.2.5-300.fc23.x86_64
Joachim Backes <joachim.backes(a)rhrk.uni-kl.de>
http://www-user.rhrk.uni-kl.de/~backes/

Hello all,
I wanted to make a few suggestions/proposals to the Koji project
to get feedback.
First off, I'd like to propose that koji officially move out of
FedoraHosted and into pagure[0] so that people can easily fork, create
topic branches and open pull requests for interactive peer review.
In the event that is acceptable I would also like to propose that all
documentation move out of the Fedora Wiki and move into the koji git
repo itself under the docs directory either formatted as Sphinx[1]
reStructured Text, or markdown[2]. This could either be hosted
directly in pagure.io or in readthedocs.org[3].
>From there I would like to suggest a formal website for koji, maybe
koji.io or similar. I don't really have a preference or suggestion on
the specific url. This website would be a simple landing page for all
information that someone interested in Koji would be looking for. It
would briefly explain what koji is, provide references on how to use
it, deploy it, how to administer it, and how get involved in
development of it. My idea is that the website itself would be a
static site that is generated using something like pelican[4] or
nikola[5], the source code for the site would also live in koji's git
repository such that all content would be in a central location and
could even be shared between the site and docs where appropriate. We
could later get clever and have the website be updated automatically
when a pull request gets merged that updates it's content, but I don't
want to get ahead of myself.
In the event that is acceptable, I would also like to propose a
"recommended developer workflow" and introduce the use of the tito[6]
utility for koji to assist in both the release tasks but also for
iterative development and/or eventual CI without giving up the
standard rpm install process. I have started mocking up what I think
would be a good starting place for a workflow, it's currently a work
in progress and doesn't actually function as described for reasons I
don't yet know (koji-hub and I are fighting with the database) but
before chewing up more time working on it I wanted to make sure that
this is even something that the group at large is open to.
https://github.com/maxamillion/koji-dev
Eventually if this developer workflow (or really any documented
developer workflow) was deemed as "recommended" by the group, I would
like to also have it live within the koji git repository such that it
can be a part of the official documentation for new and potential
contributors on how to get started working with koji development and
be highlighted on the (new) proposed website.
This is effectively a multi-part "step 1", as I would like to build on
top of this and move towards having CI for the project but getting
things in a place where we can easily facilitate iterative developer
workflows is something that I consider as a prerequisite.
I'm definitely looking forward to feedback, thanks for reading this far :)
-AdamM
[0] - https://pagure.io/
[1] - http://sphinx-doc.org/
[2] - https://en.wikipedia.org/wiki/Markdown
[3] - https://readthedocs.org/
[4] - http://blog.getpelican.com/
[5] - https://getnikola.com/
[6] - https://github.com/dgoodwin/tito

Hey,
I'm using squashfs images quite often to either install them using
anaconda or boot them directly using dracut.
It would be great to get some input on the following patch, which is
surprisingly small:
https://github.com/fabiand/koji/compare/master...liveimg
I see two open issues:
- Extract the filesystem from the raw disk image (a liveimg squashfs
just contains the raw fs image, not a disk image)
- Add support to handle this new archive type in the schem upgrade of
the database (I need some help with that).
Greetings
fabian

I probably use koji in a bit different way than Fedora maintainers as I
do not concentrate on few packages but instead check which ones are
broken (mostly on aarch64 secondary architecture).
My workflow goes like that:
1. package "xyz" fails on aarch64
2. check logs to find out is it dependency or build issue
3. check how situation on primary look
4. check how it looks on other secondary architectures
5. check bugs reported against package (there could be fix)
6. do local build
7. work on fixing
8. create patch
9. do scratch build on primary/secondaries
10. provide patch via bugzilla/irc/git
So the question is: are there plans to integrate primary and secondary
architectures into one koji?
This would allow to present state of each architecture/tag:
packagename
-----------------------------------------------------------------------
x86-64 | OK 1.2-3.fc24 | FAIL 1.1-7.fc23 | OK 1.1-2.fc22
i686 | OK 1.2-3.fc24 | FAIL 1.1-7.fc23 | OK 1.1-2.fc22
armhf | OK 1.2-3.fc24 | FAIL 1.1-7.fc23 | OK 1.1-2.fc22
aarch64 | FAIL 1.2-2.fc24 | OK 1.1-6.fc23 | OK 1.1-2.fc22
ppc64 | OK 1.2-1.fc24 | FAIL 1.1-7.fc23 | OK 1.1-2.fc22
ppc64le | OK 1.2-1.fc24 | FAIL 1.1-7.fc23 | OK 1.1-2.fc22
s390 | OK 1.2-3.fc24 | FAIL 1.1-7.fc23 | OK 1.1-2.fc22
s390x | OK 1.2-3.fc24 | FAIL 1.1-7.fc23 | OK 1.1-2.fc22
Then both package maintainers and architecture maintainers will see how
situation looks like. All newer NVRs would wait in a queue like it is
now with koji-shadow setups. And with links to builds being present in
this table it would be easier to follow ftbfs situations.
How it looks now? Koji web interface provides list of completed or
failed builds. If I see that 'somename' failed then I have to check all
builds of it to check did it completed in newer NVR or not. Or write
scripts which will follow fedmsg and query all koji instances (there are
at least two such on my hard drive).