gmane.linux.redhat.fedora.buildsystem

Manually running mock

Moray Henderson — 2012-05-25T16:21:34

3 weeks ago, before I went on holiday, I could debug build problems by
logging into my koji build server and get into the mock chroot with
something like

  su - kojibuilder -c "mock -v -r koji/slsbox-1.1-build-186-252 --shell"

Now when I try it, it fails with

  Traceback (most recent call last):
    File "/usr/sbin/mock", line 881, in <module>
      main(retParams)
    File "/usr/sbin/mock", line 759, in main
      sys.exit(chroot.shell(options, cmd))
    File "/usr/lib/python2.6/site-packages/mockbuild/backend.py", line 682,
in shell
      cmd=cmd)
    File "/usr/lib/python2.6/site-packages/mockbuild/util.py", line 402, in
doshell
      return subprocess.call(cmdstr, preexec_fn=preexec, env=environ,
shell=True)
    File "/usr/lib64/python2.6/subprocess.py", line 478, in call
      p = Popen(*popenargs, **kwargs)
    File "/usr/lib64/python2.6/subprocess.py", line 639, in __init__
      errread, errwrite)
    File "/usr/lib64/python2.6/subprocess.py", line 1228, in _execute_child
      raise child_exception
  OSError: [Errno 2] No such file or directory

I've done a mock clean and mock init, and the same thing happens.  Anyone
seen anything like that before?


Moray.
"To err is human; to purr, feline."





--
buildsys mailing list
buildsys< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

mockchain branch in mock

seth vidal — 2012-05-23T18:04:03

I added a mockchain to mock's git repo today which includes
modifications to include mockchain in mock - include specfile, makefile
and man pages.

Clark, let me know if there is anything else you need to merge this in.

Thanks,
-sv
--
buildsys mailing list
buildsys< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

pungi --discs option

Amit Saha — 2012-05-20T10:20:44

Hello:

I just signed up for this list.

The pungi manual page seemes to suggest a --discs option, whereas if
specified, as a command line argument, says: "pungi: error: no such
option: --discs".

Perhaps the manual page is dated?

Best,
Amit

koji wsgi support

Mike McLean — 2012-05-10T21:59:03

I just pushed a large commit adding wsgi support to koji-hub and 
koji-web. This feature had been on the back burner for a while, but the 
recent retirement of mod_python in Fedora has forced the issue.

Here's the summary I wrote for the (squashed) commit:
Support wsgi in koji-hub and koji-web
  - mod_python still supported, but deprecated
  - mod_wsgi is the default
  - koji-web now configured via web.conf
  - new wsgi-friendly publisher for koji-web
  - koji-web now has logging

This is a fairly large change. I've gone out of my way to maintain 
compatibility with mod_python, but migration issues are still possible.

Ideally, though, folks will move to mod_wsgi. This will mainly be a 
matter of adjusting httpd.conf files and moving koji-web config from 
http conf to the new web.conf file. I'll write a longer doc on this 
later, but for now:
- see the comments in the example http.conf files for hub and web
- see the example web.conf
- generally the web.conf options have the same name as the old koji-web 
PythonOptions

I'm not quite ready to cut a release with this yet, but soon. There 
needs to be more testing.

If you opt to try out the new code, please report bugs in our trac:
https://fedorahosted.org/koji/report
--
buildsys mailing list
buildsys< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

Unable to finish the creation of source ISO on f17

William F. Acker WB2FLW +1 303 722 7209 — 2012-05-02T14:03:06

Hi all,

      When I try to do a Pungi run, my first for f17, I get this.
Traceback (most recent call last):
   File "/bin/pungi", line 256, in <module>
     main()
   File "/bin/pungi", line 160, in main
     mypungi.doCreateIsos()
   File "/usr/lib/python2.7/site-packages/pypungi/__init__.py", line 1148, in doCreateIsos
     pypungi.util._doRunCommand(isohybrid, self.logger)
   File "/usr/lib/python2.7/site-packages/pypungi/util.py", line 36, in _doRunCommand
     raise OSError, "Got an error from %s: %s" % (command[0], err)
OSError: Got an error from /usr/bin/isohybrid: isohybrid: /home/wacker/bm/17/source/iso/Fedora-17-source-DVD.iso: could not find boot record


My command line is:
sudo pungi -c /home/wacker/.pungi/fedora-install-fedora.ks --ver=17 --sourceisos

      I actually do get the ISO, but, of course, the checksum file isn't 
created.

      I also should mention that I get a lot of unresolvable dependencies 
errors, some would go away if I stopped excluding javadoc.

          Any ideas?


           Tia.

SCM Root

Moray Henderson — 2012-04-26T09:43:12

Ah! SCM checkout and "make sources" are run in /tmp/scmroot, not
/builddir/build/SOURCES.  That might help people writing a custom "make
sources".


Moray.
"To err is human; to purr, feline."






--
buildsys mailing list
buildsys< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

Dist tag question

Moray Henderson — 2012-04-25T14:26:40

Hi again,

I've got Koji to build rpms - but the task is still failing with the message

    GenericError: Unable to complete build: release mismatch (build: 2, rpm:
2.el6)

The different build steps are giving different results.  My .spec file
contains

  Release: %{release}%{?dist}

and my build and srpm-build groups both contain redhat-release, which
resolves to centos-release-6-2.el6.centos.7.x86_64 and contains
/etc/rpm/macros.dist to set "%dist .el6".

However buildSRPMFromSCM results in 

  Building target platforms: x86_64
  Building for target x86_64
  Wrote: /builddir/build/SRPMS/mypackage-1.0-2.src.rpm

while buildArch also builds a srpm before the binary rpm:

  Building target platforms: noarch
  Building for target noarch
  Wrote: /builddir/build/SRPMS/mypackage-1.0-2.el6.src.rpm

  Building target platforms: noarch
  Building for target noarch
  ...
  Wrote: /builddir/build/RPMS/slspkg-1.0-2.el6.noarch.rpm

My Koji hub lists the build as "mypackage-1.0-2".  If I get buildSRPMFromSCM
to use the dist macro, will the Koji hub pick up the right name?  How do I
get buildSRPMFromSCM to do that?


Moray.
"To err is human; to purr, feline."





--
buildsys mailing list
buildsys< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

mockchain.py

Seth Vidal — 2012-04-20T16:43:22

I worked on this a bit last week. I thought I'd mention it here:

http://fedorapeople.org/gitweb?p=skvidal/public_git/scripts.git;a=tree;f=mock

mockchain.py

mockchain.py [options] chrootname file.src.rpm [file1.src.rpm] 
[file2.src.rpm] ...

Builds a series of srpms in mock one at a time. After each successful 
build
of a package it adds the resulting packages to a local repo which
are available to the next package to satisfy buildreqs.

options:
  -c - continue on package build failure - by default it will exit if
       a package fails to build. set this if you wish it to try and 
continue
       for the rest of the packages.

  -l path - set the path to put the results/repo in. This path needs to be
     somewhere accessible to users other than you for reading as the
     mock process doesn't run as you.

  -a url - add this repo url to the yumconfig for the buildroot. This can
           be specified multiple times. Let's you point to multiple
           paths beyond the default to pull build deps from.

  --recurse - build all pkgs, record the failures and try to rebuild them
              again and again until everything gets built (or until the
              set of pkgs failing to build are the same over)

This does not try to sort the packages by build order b/c that is too much
effort and not obviously doable with the buildreq information we have.

The build process when you use -l is idempotent so a package which has
already been successfully built will not be built again.

If you want to force the rebuild of a package which has been built
successfully simply remove the 'success' file from the dir with the 
package
results in it. Package results are written out into
a dir named:
   chrootname/pkgname-ver-rel/

for example:
    fedora-16-x86_64/yum-3.2.29-0/



-sv

--
buildsys mailing list
buildsys< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

How does...?

Moray Henderson — 2012-04-20T16:34:27

Hello again,

I'm trying to understand how Koji does things in order to migrate from our
previous home-made build system with svn repositories to Koji.  Most of our
stuff is in svn as source files, not tarballs, so I'll have to implement a
"make sources".  I was looking in the Fedora git repositories, but couldn't
see how this is actually done.  I can see how it _used_ to be done: with a
common package containing a Makefile.common.  However that doesn't seem to
be available any more.

I've found fedora-packager and fedpkg; there was a thread here in 2010
(http://www.mail-archive.com/buildsys< at >lists.fedoraproject.org/msg00619.html)
which suggested that they configured Koji to issue the command to get the
sources.  However, that's "allowed_scms" in kojid.conf, and I can't see
anything in either package now which modifies that.

So basically I'd really like to know the steps that Fedora's Koji goes
through to build packages like anaconda - which has an old Makefile, and has
no URL to say where to find the sources.  


Moray.
"To err is human; to purr, feline."






--
buildsys mailing list
buildsys< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

Documentation discussion

Moray Henderson (ICT — 2012-04-16T15:05:30

I spotted a couple of points where I think the Koji documentation could be
improved:

In Koji/ServerHowTo#Koji_filesystem_skeleton you give an example

  kojiadmin< at >localhost$ koji add-host kojibuilder1 x86_64 i386

which looks as if a simple user name style is sufficient.  Near the end of
the same document, in
Koji/ServerHowTo#Add_the_host_entry_for_the_koji_builder_to_the_database,
you say it like this:

  kojiadmin< at >localhost$ koji add-host kojibuilder1.example.com i386 x86_64

Now it looks as if you're supposed to use the full host name, not a user
name.  It would be good to make those entries consistent and, if you do need
the FQDN, to explain why.


In
Koji/ExternalRepoServerBootstrap#Bootstrapping_a_new_External_Repo_Koji_buil
d_environment you have a note

  * NOTE: If you are adding multiple external repos, koji assigns a priority
to each repo in FIFO order. This may cause updated packages to not be
visible if a repo with older packages is ranked at a higher priority (lower
numeric value). Use the -p flag to set specific repo priorities.

That suggests that repos with newer packages should be added first:

  testing/\$arch
  updates/\$arch
  os/\$arch

However in
Koji/ExternalRepoServerBootstrap#Examples_of_urls_to_use_for_external_Reposi
tories your examples list the os  release repo before the updates repo,
which would give the repo with the older packages the lower numeric value
and therefore the higher priority.


Moray.
"To err is human; to purr, feline."




  OM International Limited - Unit B Clifford Court, Cooper Way - Carlisle CA3 0JG - United Kingdom
  Charity reg no: 1112655 - Company reg no: 5649412 (England and Wales)

--
buildsys mailing list
buildsys< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

rescue mode and lvm

Sérgio Basto — 2012-04-15T21:54:53

Hi, 
from http://fedorasolved.org/Members/zcat/shrink-lvm-for-new-partition 
"Boot into rescue mode and on the last step make sure to SKIP mounting
your filesystems under /mnt/sysimage
Activate LVM 
  * lvm vgchange -a y"


If I boot into rescue mode at the not skip mounting, I got a message
that can't find any (lvm) partitions.

but could be good mounting my filesystems even if a lvm ? 
if yes, rescue mode should active LVM, before scan for partitions with
Linux .

I check with F17 boot.iso and also the same with F16 boot.iso .

Thanks,

newRepo Permission denied: '/mnt/koji/repos'

Moray Henderson — 2012-04-12T15:40:08

Is this the right place for questions on local koji installations?

Fresh setup of koji on CentOS 6.2.  I've got hub, web and builder all
talking to each other, external repositories defined for the build tag and
build groups set up.  

/mnt/koji is an nfs mount with root squashed to uid 48 (apache).  I've
tested that I can write to the subdirectories as root and the owner comes
out as apache.  The directory looks like

  # ll -R koji
  koji:
  total 16
  drwxr-xr-x 2 apache apache 4096 Apr 12 11:13 packages
  drwxr-xr-x 3 apache apache 4096 Apr 12 15:20 repos
  drwxr-xr-x 2 apache apache 4096 Apr 12 11:13 scratch
  drwxr-xr-x 2 apache apache 4096 Apr 12 11:13 work

  koji/packages:
  total 0

  koji/repos:
  total 0

  koji/scratch:
  total 0

  koji/work:
  total 0

The Koji/ExternalRepoServerBootstrap document says "Wait for the repo to
regenerate, and you should now be able to run a build successfully."
However, Koji-web lists the newRepo task as failed with result "<type
'exceptions.OSError'>: [Errno 13] Permission denied: '/mnt/koji/repos'".  On
the builder, kojid.log reports:

  2012-04-12 14:20:31,067 [INFO] koji.build: Starting up
  2012-04-12 14:20:34,363 [INFO] koji.TaskManager: Attempting to take task
176
  2012-04-12 14:20:36,275 [INFO] koji.TaskManager: pids: {176: 17925}
  2012-04-12 14:20:36,855 [WARNING] koji.TaskManager: FAULT:
  Traceback (most recent call last):
    File "/usr/lib/python2.6/site-packages/koji/daemon.py", line 1114, in
runTask
      response = (handler.run(),)
    File "/usr/lib/python2.6/site-packages/koji/tasks.py", line 146, in run
      return self.handler(*self.params,**self.opts)
    File "/usr/sbin/kojid", line 2491, in handler
      repo_id, event_id = self.session.host.repoInit(tinfo['id'], **kwargs)
    File "/usr/lib/python2.6/site-packages/koji/__init__.py", line 1510, in
__call__
      return self.__func(self.__name,args,opts)
    File "/usr/lib/python2.6/site-packages/koji/__init__.py", line 1760, in
_callMethod
      raise err
  Fault: <Fault 1: "<type 'exceptions.OSError'>: [Errno 13] Permission
denied: '/mnt/koji/repos'">

  2012-04-12 14:20:37,110 [INFO] koji.TaskManager: open task: {'waiting':
None, 'id': 176, 'weight': 0.10000000000000001}


I've looked into the code, but my python is not up to debugging that.  It's
not an SELinux problem (I tried permissive mode) and /mnt/koji is mounted
read-write on the builder even though the documentation says that's not
necessary.  Can someone point me in the right direction?


Moray.
"To err is human; to purr, feline."


--
buildsys mailing list
buildsys< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

logfile rotation for kojid builder

Florian La Roche — 2012-04-09T18:10:01

Hello,

the default "kojid" builder is using /var/log/kojid.log
for file logging via:
    handler = logging.handlers.RotatingFileHandler(fn, maxBytes=1024*1024*10, backupCount=5)

This does not seem to work if kojid forks and rotation happens within
the forked processes and then the main process is still using the old
kojid.log file...
So rotation should probably move into the main kojid process.

Keeping to the old logfile can be easily seen in /proc/<pid kojid>/fd/.

best regards,

Florian La Roche

--
buildsys mailing list
buildsys< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

Regular Koji cleanup

Anthony Messina — 2012-04-06T11:35:36

It was mentioned in
http://lists.fedoraproject.org/pipermail/buildsys/2012-April/003838.html
that some manual DB cleanup is in order from time to time.

I also run a private Koji instance and am wondering if there are other
regular maintenance activities that should be run other than those
provided by koji-gc and removing old scratch and work directories?

Are there other DB commands that should be run to keep things pruned down?

Thanks.  -A

koji: small patch to fix warnings

John Morris — 2012-04-04T17:16:42

After the koji.conf 'pkgurl' attribute was enabled (sigul wants this; 
I'll submit a patch for that too, later), one of my scripts broke 
because the "Warning: the pkgurl option is obsolete" message is printed 
to stdout instead of stderr.  Here's a little patch to print the warning 
with the warn() function instead.

I realize some warnings from the cli might be best printed to stdout, 
but for ones that might appear when using a computer-readable type of 
command like 'list-* --quiet', stderr seems like the better choice.

Thanks-

John
--
buildsys mailing list
buildsys< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

sessions table cleanup ?

Thomas Guthmann — 2012-04-03T08:35:09

Hey guys,

We are running our own private koji instance. We are running 1.6 on el5.
Lately this query takes 20mins or so to execute :

     SELECT host.id,name,arches,task_load,capacity FROM host
         JOIN sessions USING (user_id)
     WHERE enabled = TRUE AND ready = TRUE
         AND expired = FALSE
         AND master IS NULL
         AND update_time > NOW() - '5 minutes'::interval

It looks like the 'sessions' table is the culprit. Indeed SELECTing 
'host' is immediate whereas SELECT count(id) from 'sessions' takes 15 
seconds for only 408312 rows... looks like a vacuum problem you would 
say. You are right but my question is why do I have so many sessions 
rows ? Can 'sessions' be truncated ? I am just wondering if it's a known 
issue to not clean the sessions tables or if I need to tune my 
autovacuum to work properly :)

Cheers,
Thomas

--
buildsys mailing list
buildsys< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

Fedora 17, Koji, systemd

Anthony Messina — 2012-03-23T14:47:55

Are there plans for the upcoming Fedora 17 koji daemons (koji-builder,
kojira) to be build with systemd support?

Thanks.  -A

Pungi fails within mock - 'AttributeError: prerepoconf'

Clint Savage — 2012-03-01T17:17:01

While following this guide:
http://fedoraproject.org/wiki/How_to_create_a_Fedora_install_ISO_for_testing#Build_a_DVD.iso,
I've received an interesting error:

    $ mock -r goose-sketchy-x86_64 --shell
    INFO: mock.py version 1.1.18 starting...
    State Changed: init plugins
    INFO: selinux disabled
    State Changed: start
    State Changed: lock buildroot
    State Changed: shell
    <mock-chroot>[root< at >pilgrim /]# pungi -G -C -B --flavor=GoOSe
--ver=sketchy -c /root/pungi-x86_64.ks
    Warning: Reusing existing destination directory.
    Traceback (most recent call last):
    File "/usr/bin/pungi", line 216, in <module>
    main()
    File "/usr/bin/pungi", line 86, in main
    mypungi._inityum() # initialize the yum object for things that need it
    File "/usr/lib/python2.6/site-packages/pypungi/__init__.py", line
166, in _inityum
    del self.ayum.prerepoconf
    AttributeError: prerepoconf

A couple things to note:

pungi was built by me from the latest that seemed to work with
something equivalent to CentOS6.0 on our koji server -

pungi-2.0.22-1.gl6.noarch.

Here are the mock and yum versions as well:

mock-1.1.18-1.el6.noarch
yum-3.2.29-22.el6.centos.noarch

I did have a look through the mock logs to no avail.

Any thoughts?

Anything else I can provide, please just let me know.

Thanks,

Clint
--
buildsys mailing list
buildsys< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

Specific builder creating Asterisk builds with "invalid opcode"

Anthony Messina — 2012-02-08T05:48:14

I have a small private Koji setup here which has worked well for quite
some time.  I have only two builders, both running up to date x86_64
Fedora 16.  I am having a strange issue where when I build Asterisk 10
for Fedora 15 x86_64 on one of the builders, Asterisk will fail to start
with an invalid 'opcode message'.  However, If I build it on the other
builder, Asterisk will work as expected.

I am truly not sure where to begin, but I've only seen this issue start
to occur within the last month or so.

The only real difference between the two builders are the CPUs.  Showing
the first of each below, the builder that produces Asterisk builds which
fail is:

~]# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Core(TM) i7-2600 CPU < at > 3.40GHz
stepping        : 7
microcode       : 0x25
cpu MHz         : 1600.000
cache size      : 8192 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx
smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt
tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts
dts tpr_shadow vnmi flexpriority ept vpid
bogomips        : 6784.77
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:


And the builder that produces a working Asterisk build is:
~]# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 6
model name      : Intel(R) Pentium(R) D CPU 2.80GHz
stepping        : 4
microcode       : 0x4
cpu MHz         : 2800.000
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 6
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx lm constant_tsc pebs bts nopl pni dtes64 monitor ds_cpl est
cid cx16 xtpr pdcm lahf_lm
bogomips        : 5585.86
clflush size    : 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:

The (first) CPU of the Fedora 15 x86_64 system on which I am attempting
to run the Asterisk build is:
~]# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      : Intel(R) Xeon(TM) CPU 2.80GHz
stepping        : 3
cpu MHz         : 2800.000
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx lm constant_tsc pebs bts nopl pni dtes64 monitor ds_cpl cid
cx16 xtpr
bogomips        : 5585.42
clflush size    : 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:


As I said, I'm not even sure where to begin, so I'm not sure that
information is helpful.

The build log which creates the inoperable Asterisk:
[1080956.984634] asterisk[2294] trap invalid opcode ip:516e52
sp:7fffcfef3600 error:0 in asterisk[400000+197000]
is here:
http://messinet.com/~amessina/asterisk_invalid_opcode_build.log

The 'good' build log is here:
http://messinet.com/~amessina/asterisk_success_build.log

The spec file is 99.9% the same as Jeffrey Ollie's official Fedora spec
file and is here:
http://messinet.com/~amessina/asterisk.spec

Thanks in advance for your help.  -A

Is it a bug of mock?

Kirby Zhou — 2012-01-17T12:25:28

/usr/lib/python2.6/site-packages/mockbuild/uid.py
mock-1.1.18-1.el6.noarch

ccache plugin calls changeOwner to take the ownership of ccache directory,
but why set gid to uid?

70     decorate(traceLog())
71     def changeOwner(self, path, uid=None, gid=None):
72         self._elevatePrivs()
73         if uid is None:
74             uid = self.unprivUid
75         if gid is None:
76             gid = uid
77         os.chown(path, uid, gid)

Regards
Kirby Zhou
+86 (10) 6272 8261

--
buildsys mailing list
buildsys< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

Adding kernel modules to the installation tree.

William F. Acker WB2FLW +1 303 722 7209 — 2012-01-10T05:31:36

Hi all,

      The question is really: how do I stop Lorax from removing kernel 
modules that I need. I can't find any documentation on the configuration 
file for Lorax.

           TIA.