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_excepti

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 
P

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?

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

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

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 source

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

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

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 equivalen

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

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.