local / scratch builds with fedpkg

[David Woodhouse]

I have a modified package locally and want to install and test it. Since
it's a biarch package, I need to build the i686 version too. How?

A local build no longer seems to work for anything but the primary arch,
because it still configures for x86_64:

$ i386 fedpkg local --arch=i686
...
+ ./configure --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --program-prefix=
--disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib
--libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib
--mandir=/usr/share/man --infodir=/usr/share/info --disable-gtk-doc
--enable-static --with-runtime-libdir=../../lib

And scratch-build doesn't seem to work either. It won't let me build
unless I push.... but I thought the whole point of a scratch build was
to test stuff I'm not yet *ready* to push (and I'm not even the
maintainer of this package).

$ fedpkg scratch-build
Traceback (most recent call last):
File "/usr/bin/fedpkg", line 959, in <module>
args.command(args)
File "/usr/bin/fedpkg", line 573, in scratchbuild
build(args)
File "/usr/bin/fedpkg", line 319, in build
url, chain)
File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line
797, in build
raise FedpkgError('There are unpushed changes in your repo')
pyfedpkg.FedpkgError: There are unpushed changes in your repo

[Paul Howarth]

Post by David Woodhouse
I have a modified package locally and want to install and test it. Since
it's a biarch package, I need to build the i686 version too. How?
A local build no longer seems to work for anything but the primary arch,
$ i386 fedpkg local --arch=i686
...
+ ./configure --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --program-prefix=
--disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib
--libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib
--mandir=/usr/share/man --infodir=/usr/share/info --disable-gtk-doc
--enable-static --with-runtime-libdir=../../lib
And scratch-build doesn't seem to work either. It won't let me build
unless I push.... but I thought the whole point of a scratch build was
to test stuff I'm not yet *ready* to push (and I'm not even the
maintainer of this package).
$ fedpkg scratch-build
File "/usr/bin/fedpkg", line 959, in<module>
args.command(args)
File "/usr/bin/fedpkg", line 573, in scratchbuild
build(args)
File "/usr/bin/fedpkg", line 319, in build
url, chain)
File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line
797, in build
raise FedpkgError('There are unpushed changes in your repo')
pyfedpkg.FedpkgError: There are unpushed changes in your repo

The scratch-build Make target used to work with committed and tagged
files in CVS. Unpushed changes could be tested using "make
srpm-scratch-build" but fedpkg doesn't have an srpm-scratch-build yet
(hint, hint).

For the moment I've been doing "fedpkg srpm" and running koji scratch
builds manually with the resulting SRPM.

Paul.

[Adam Jackson]

Post by David Woodhouse
$ i386 fedpkg local --arch=i686
...
+ ./configure --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --program-prefix=
--disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib
--libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib
--mandir=/usr/share/man --infodir=/usr/share/info --disable-gtk-doc
--enable-static --with-runtime-libdir=../../lib

'i386 fedpkg mockbuild' should work, although that's not what you asked
for.

Post by David Woodhouse
$ fedpkg scratch-build
File "/usr/bin/fedpkg", line 959, in <module>
args.command(args)
File "/usr/bin/fedpkg", line 573, in scratchbuild
build(args)
File "/usr/bin/fedpkg", line 319, in build
url, chain)
File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line
797, in build
raise FedpkgError('There are unpushed changes in your repo')
pyfedpkg.FedpkgError: There are unpushed changes in your repo

% fedpkg scratch-build --help
usage: fedpkg scratch-build [-h] [--nowait] [--background]
[--arches [ARCHES [ARCHES ...]]] [--srpm SRPM]

optional arguments:
-h, --help show this help message and exit
--nowait Don't wait on build
--background Run the build at a lower priority
--arches [ARCHES [ARCHES ...]]
Build for specific arches
--srpm SRPM Build from srpm

I suspect --srpm is what you're looking for.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100803/2d383ed8/attachment.bin

[Adam Williamson]

Post by David Woodhouse
I have a modified package locally and want to install and test it. Since
it's a biarch package, I need to build the i686 version too. How?

Is there a reason not to use mock locally? That's how I'd do it - just
'fedpkg srpm' then 'mock -r fedora-14-i386 --rebuild foo.src.rpm' .
You'll need mock 1.1.3 to do successful builds on / for F14, though.
http://koji.fedoraproject.org/koji/buildinfo?buildID=188082

[Paul Howarth]

Post by Adam Williamson

Post by David Woodhouse
I have a modified package locally and want to install and test it. Since
it's a biarch package, I need to build the i686 version too. How?

Is there a reason not to use mock locally?

I might want to try a build for an architecture I can't do locally, such
as a ppc64 build for EPEL.

Post by Adam Williamson
That's how I'd do it - just
'fedpkg srpm' then 'mock -r fedora-14-i386 --rebuild foo.src.rpm' .
You'll need mock 1.1.3 to do successful builds on / for F14, though.
http://koji.fedoraproject.org/koji/buildinfo?buildID=188082

Huh? I don't seem to be having any trouble building F14/F15 packages on
my F13 builder with mock 1.1.1 at the moment.

Paul.

[Adam Williamson]

Post by Paul Howarth

Post by Adam Williamson

Post by David Woodhouse
I have a modified package locally and want to install and test it. Since
it's a biarch package, I need to build the i686 version too. How?

Is there a reason not to use mock locally?

I might want to try a build for an architecture I can't do locally, such
as a ppc64 build for EPEL.

Post by Adam Williamson
That's how I'd do it - just
'fedpkg srpm' then 'mock -r fedora-14-i386 --rebuild foo.src.rpm' .
You'll need mock 1.1.3 to do successful builds on / for F14, though.
http://koji.fedoraproject.org/koji/buildinfo?buildID=188082

Huh? I don't seem to be having any trouble building F14/F15 packages on
my F13 builder with mock 1.1.1 at the moment.

That's a neat trick, since 1.1.1 didn't even have configs for Fedora 14.
They were added in 1.1.2, but were broken, since they enabled the
'updates' repository, which doesn't work for F14. Additionally there's a
problem with the SELinux plugins in 1.1.2 which broke building for me.
1.1.3 fixes the F14 mock config and the SELinux plugin problems.

[Paul Howarth]

On Wed, 04 Aug 2010 09:47:43 -0700

Post by Adam Williamson

Post by Paul Howarth

Post by Adam Williamson

Post by David Woodhouse
I have a modified package locally and want to install and test
it. Since it's a biarch package, I need to build the i686
version too. How?

Is there a reason not to use mock locally?

I might want to try a build for an architecture I can't do locally,
such as a ppc64 build for EPEL.

Post by Adam Williamson
That's how I'd do it - just
'fedpkg srpm' then 'mock -r fedora-14-i386 --rebuild
foo.src.rpm' . You'll need mock 1.1.3 to do successful builds
on / for F14, though.
http://koji.fedoraproject.org/koji/buildinfo?buildID=188082

Huh? I don't seem to be having any trouble building F14/F15
packages on my F13 builder with mock 1.1.1 at the moment.

That's a neat trick, since 1.1.1 didn't even have configs for Fedora 14.

I roll all of my own mock configs, with different names from the bundled
ones so they don't disappear when a new mock version comes around.

Post by Adam Williamson
They were added in 1.1.2, but were broken, since they enabled the
'updates' repository, which doesn't work for F14. Additionally
there's a problem with the SELinux plugins in 1.1.2 which broke
building for me. 1.1.3 fixes the F14 mock config and the SELinux
plugin problems.

I've been using my own workaround for SELinux issues:

http://lists.fedoraproject.org/pipermail/buildsys/2010-April/003055.html

Not sure what the SELinux plugin does; do you know of any documentation
for it?

Paul.

[Adam Williamson]

Post by Paul Howarth

Post by Adam Williamson
That's a neat trick, since 1.1.1 didn't even have configs for Fedora 14.

I roll all of my own mock configs, with different names from the bundled
ones so they don't disappear when a new mock version comes around.

Post by Adam Williamson
They were added in 1.1.2, but were broken, since they enabled the
'updates' repository, which doesn't work for F14. Additionally
there's a problem with the SELinux plugins in 1.1.2 which broke
building for me. 1.1.3 fixes the F14 mock config and the SELinux
plugin problems.

http://lists.fedoraproject.org/pipermail/buildsys/2010-April/003055.html
Not sure what the SELinux plugin does; do you know of any documentation
for it?

Okay, then, clearly, I should have said: "If you use the bundled mock
configs and don't figure out your own workaround for SELinux bugs, you
will need mock 1.1.3 to build for F14'. (/me looks around desperately
for the email 'rolleyes' smiley).

No idea what the selinux plugin does, no.