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?
Bill in Denver
using boot.iso from releases/12/Fedora/x86_64/os/images/
I can do a usb boot disc and run the rescue mode, easily, with command
livecd-iso-to-disk boot.iso /dev/sdc
And install.img is write on /images.
I also could update install.img using method wrote in :
but I don't know how or where
with /usr/lib/anaconda-runtime/buildinstall and/or pungi -B , can
customize my install.img.
For example I'd like add lynx (to install.img), how I can do that ?
Other question rescue mode don't have any web browser text based ?
Thanks in advance,
Sérgio M. B.
Hi all and welcome me to the list :),
i'm using koji since a few week and i needed X509 authentication.
Unfortunately current support for x509 was limited to:
a) Use of the CN part only from the subject DN as the username
Although traditionally CN can be the "username" of the user there
are cases (like in our PKI) where CN is just "Christos
Triantafyllidis" and of course many users can have the same name but
different DNs. To avoid this but also keep the backwards compatibility
i have introduced a new variable to be exported by both apache config
(for git-web) and hub.conf (for the rest of the tools) called
EnvVarForUserName which defines which variable to use as Username. For
my case i have "EnvVarForUserName = SSL_CLIENT_S_DN" which uses the
whole DN as username.
b) Keep asking the user to provide their pass-phrase many times for
the the same operation
This leads (IMHO) many users to use password-less certificates.
Unfortunately this is not acceptable according to our PKI policy so i
added a callback to cache the passphrase within each koji execution.
I have created some patches to both this limitations and i have
uploaded the to my git repository. Feel free to use/clone them.
Recently, one of my building hosts's mock directory usually be filled with
build directories, I wonder why the build directories of finishing building
task not to be removed immediately for make room for the coming task , yet
they don't stay here untill some time elapses. So, When and how the mock
removes the build directories under the "/var/lib/mock" in koji building
Is there a way I can keep my builds away from the ppc builders? I'm trying to push an update to my noarch (java) package (http://koji.fedoraproject.org/koji/taskinfo?taskID=1847061) but it seems to end up on a ppc64 builder and fail miserably )-:
Now I promise I will try to dig in to the root cause of the build failure but since ppc no longer is a primary architecture, the failed build on PPC shouldn't hold up the release on the primary architectures.