Heads up: waf 1.5
by Thomas Moschny
Hi!
I'd like to update waf [1] to version 1.5.0 (which has been released
only recently, and changes apis) for rawhide, and also as an update
for f10. As far as I can see, only midori depends on it (although some
more packages probably should, like kdissert).
Any objections?
Regards,
Thomas
[1] http://code.google.com/p/waf/
--
Thomas Moschny <thomas.moschny(a)gmail.com>
15 years, 2 months
mock 0.8.9 will not build anything
by Frank Büttner
Hello,
when I try to build an package mock will fail with:
ERROR: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs for
output.
At the root.log:
2008-01-18 09:48:01,860 - DEBUG trace_decorator.py, Line: 20: ENTER:
doChroot((<mock.backend.Root object at 0xb7dc8e8c>, '/usr/sbin/grou
padd -g 102 mockbuild', ''), {})
2008-01-18 09:48:01,861 - DEBUG trace_decorator.py, Line: 20: ENTER:
do(('/usr/sbin/groupadd -g 102 mockbuild', '/var/lib/mock/fedora-de
velopment-i386/root', 0, True, 0, None, None, None, None), {})
2008-01-18 09:48:01,862 - DEBUG util.py, Line: 212: Run cmd:
/usr/sbin/groupadd -g 102 mockbuild
2008-01-18 09:48:01,862 - DEBUG util.py, Line: 218: Executing
timeout(0): /usr/sbin/groupadd -g 102 mockbuild
2008-01-18 09:48:01,866 - DEBUG trace_decorator.py, Line: 20: ENTER:
condPersonality((None,), {})
2008-01-18 09:48:01,869 - DEBUG trace_decorator.py, Line: 30: LEAVE
condPersonality --> None
2008-01-18 09:48:01,870 - DEBUG trace_decorator.py, Line: 20: ENTER:
condChroot(('/var/lib/mock/fedora-development-i386/root', None), {}
)
2008-01-18 09:48:01,871 - DEBUG trace_decorator.py, Line: 30: LEAVE
condChroot --> None
2008-01-18 03:48:01,872 - DEBUG trace_decorator.py, Line: 20: ENTER:
condDropPrivs((None, None, None), {})
2008-01-18 03:48:01,873 - DEBUG trace_decorator.py, Line: 30: LEAVE
condDropPrivs --> None
2008-01-18 09:48:01,973 - DEBUG util.py, Line: 234: groupadd: name
mockbuild is not unique
2008-01-18 09:48:01,977 - DEBUG trace_decorator.py, Line: 27:
EXCEPTION: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs f
or output.
Any ideas, what goes wrong??
Frank
15 years, 2 months
Automatic BuildRequires
by Richard W.M. Jones
[I'm sure this isn't the first time this has occurred to someone, or
even been done -- but couldn't find anything for it in Google ...]
http://et.redhat.com/~rjones/auto-buildrequires/
This tries to find the correct set of BuildRequires automatically when
running 'rpmbuild'. Just replace the ordinary rpmbuild command with
auto-br-rpmbuild, and it will print out a suggested set of
BuildRequires lines at the end. For example:
$ auto-br-rpmbuild -ba mingw32-iconv.spec
[...]
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/rjones/rpmbuild/BUILDROOT/mingw32-iconv-1.12-5.fc10.x86_64
Wrote: /home/rjones/rpmbuild/SRPMS/mingw32-iconv-1.12-5.fc10.src.rpm
Wrote: /home/rjones/rpmbuild/RPMS/noarch/mingw32-iconv-1.12-5.fc10.noarch.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.XpFhTF
+ umask 022
+ cd /home/rjones/rpmbuild/BUILD
+ cd libiconv-1.12
+ rm -rf /home/rjones/rpmbuild/BUILDROOT/mingw32-iconv-1.12-5.fc10.x86_64
+ exit 0
BuildRequires: bash = 3.2.29.fc10.x86_64
BuildRequires: binutils = 2.18.50.0.9.7.fc10.x86_64
BuildRequires: ccache = 2.4.13.fc9.x86_64
BuildRequires: coreutils = 6.12.16.fc10.x86_64
BuildRequires: diffutils = 2.8.1.21.fc9.x86_64
BuildRequires: file = 4.26.3.fc10.x86_64
BuildRequires: findutils = 1:4.4.0.1.fc10.x86_64
BuildRequires: gawk = 3.1.5.18.fc10.x86_64
BuildRequires: gcc-gfortran = 4.3.2.6.x86_64
BuildRequires: gettext = 0.17.8.fc10.x86_64
BuildRequires: glibc-common = 2.8.90.14.x86_64
BuildRequires: grep = 2.5.1a.61.fc10.x86_64
BuildRequires: gzip = 1.3.12.7.fc10.x86_64
BuildRequires: make = 1:3.81.14.fc10.x86_64
BuildRequires: mingw32-binutils = 2.18.50_20080109_2.8.fc9.x86_64
BuildRequires: mingw32-filesystem = 34.1.fc9.noarch
BuildRequires: mingw32-gcc-c++ = 4.3.2.8.fc9.x86_64
BuildRequires: mingw32-gcc = 4.3.2.8.fc9.x86_64
BuildRequires: mingw32-gettext = 0.17.6.fc9.noarch
BuildRequires: mingw32-iconv = 1.12.4.fc9.noarch
BuildRequires: mingw32-runtime = 3.15.1.1.fc9.noarch
BuildRequires: mingw32-w32api = 3.12.1.fc9.noarch
BuildRequires: net-tools = 1.60.91.fc10.x86_64
BuildRequires: sed = 4.1.5.10.fc9.x86_64
BuildRequires: tar = 2:1.20.3.fc10.x86_64
As you can see it's not perfect. It doesn't ignore 'core' packages
which are always expected in a mock/koji build. Also because autoconf
scripts tend to touch the C++ and Fortran compilers, even when they
are not used, it always suggests those packages. Also it doesn't
exclude some tools like tar which are touched by rpmbuild itself.
The implementation is a simple LD_PRELOAD script that analyzes open(2)
and execve(2) system calls, a Perl script that does the analysis, and
some shell scripts to hang it all together.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
15 years, 3 months
Multiple packages from one tarball and spec file
by Trever L. Adams
My questions concerning projects which are from SVN and not tarballs
hasn't yet been answered. Some projects don't release tarballs or
haven't released recent ones (and may not). Are this acceptable in Fedora?
Additionally, I have several packages I am thinking of doing (some of
which I have spec files for already). However, I am displeased with a
few of them that come from one tarball. There are several options
(crm114, dspam, or mailing back-ends for example) for dovecot-antispam.
The problem is, you cannot build one module for dovecot that does them
all, so the module has to be rebuilt with slightly different options and
must conflict with all other dovecot-antispam RPMs. Is possible from one
spec file and tarball? This would require different setup, build,
install and package setups. This is because the same module would be
built for each area, need to be packaged, and then move onto the rest.
Thank you for any help on the first paragraph or the second.
Trever
15 years, 3 months
f11 boost-1.37.0 upgrade: notice of intent, and best way to
by Benjamin De Kosnik
The boost maintainers are planning to update the boost versions
to the current release (1.37.0) in rawhide for F11. There was an
attempt to upgrade boost for F10, but the timing was off.
Details on that attempt:
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00464.html
We have a tenative (local) srpm, and intend with this announcement to
put the boost upgrade in the queue for F11. Consider yourself notified,
devel-list reader.
There is some general discussion of how changes with a lot of deps
should be brought into rawhide:
1) making a koji tag, check in new boost, rebuild deps
2) mock chroot with the new boost, rebuild deps
Suggestions? Actual instructions, written down somewhere? The other
option is to:
3) check in the base boost package to devel, and immediately work on
rebuilding the deps
I don't want to jump the gun here, as I know F11 planning is ongoing,
and that holiday scheduling is a concern. Thoughts, and suggestion on
how to proceed are welcome.
best,
benjamin
15 years, 3 months