Manually running mock

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?

mockchain branch in mock

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

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

--

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

koji wsgi support

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
--

Unable to finish the creation of source ISO on f17

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.

--

-- 
           Bill in Denver

Re: SCM Root

On 04/26/2012 05:43 AM, Moray Henderson wrote:
> Ah! SCM checkout and "make sources" are run in /tmp/scmroot, not
> /builddir/build/SOURCES.  That might help people writing a custom "make
> sources".

A 'make sources' target that cares about the name of the checkout 
directory is arguably broken.
--
buildsys mailing list
buildsys <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

SCM Root

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

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

RE: How does...?

Thanks everyone - your replies have been very helpful.

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

Re: How does...?

On 04/20/2012 12:34 PM, Moray Henderson wrote:
> 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.

The allowed_scms option in kojid specifies which scms can be used and 
how kojid should use them. The format of the option is:

"""
a space-separated list of host:repository[:use_common[:source_cmd]] 
tuples.  Incorrectly-formatted tuples will be ignored.

If use_common is not present, kojid will attempt to checkout a common/ 
directory from the repository.  If use_common is set to no, off, false, 
or 0, it will not attempt to checkout a common/ directory.

source_cmd is a shell command (args separated with commas instead of 
spaces) to run before building the srpm. It is generally used to 
retrieve source files from a remote location.  If no source_cmd is 
specified, "make sources" is run by default.
"""

So...
- if you were using an old dist-cvs setup, you'd set use_common to yes 
and leave source_cmd as the default.
- with a dist-git setup, you'd set use_common to no and source_cmd to 
fedpkg,sources
- for simpler setups, you might simply set use_common to no, leave 
source_cmd as the default, and ensure that each package to be built 
includes a Makefile with a sources target that does the right thing.

Re: How does...?

On Fri, 2012-04-20 at 17:34 +0100, Moray Henderson wrote:

> 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.

I wouldn't assume that the baseline configuration of the koji package in
Fedora necessarily matches how Fedora's koji instance is deployed.

> 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.  

Well, the way you do this as a fedpkg user is just run "fedpkg sources",
which grabs tarballs from the lookaside server based on the names and
md5sums in the 'sources' file in the checked-out package.  Which is how
"make sources" used to work, too.

From a quick look at the kojid source I'd assume you'd want to override
the 'source_cmd' attribute of the SCM to do whatever's appropriate.

- ajax

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