Looking at http://cvs.fedoraproject.org/viewcvs/comps/comps-f9.xml.in?view=markup
I find that Glade2 and Anjuta are marked as default and optional
respectively. While Glade 3.4.1 (separate package from Glade2) is
already there in the repositories, we are soon going to have a fresh
new Anjuta package (atleast 2.2.3) in Fedora.
However, the latest versions of Anjuta -- both 2.2.3 (stable) and
2.3.x (unstable) -- need Glade3 for its Glade plugin to work. So can
we consider replacing Glade2 by Glade3 in the comps-f9.xml.in for
Fedora 9? As far as I know, this would affect the Live Developer Spin
and the non-live GNOME DVD.
What do you think?
Free software for the Indian community:
* ftp://fedora.glug-nith.org/ (Fedora)
* http://gnu.glug-nith.org/ (GNU)
* http://mirror.wbut.ac.in/ (CRAN, Fedora, Mozilla, TLDP)
[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 ...]
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
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 = 126.96.36.199.9.7.fc10.x86_64
BuildRequires: ccache = 2.4.13.fc9.x86_64
BuildRequires: coreutils = 6.12.16.fc10.x86_64
BuildRequires: diffutils = 188.8.131.52.fc9.x86_64
BuildRequires: file = 4.26.3.fc10.x86_64
BuildRequires: findutils = 1:184.108.40.206.fc10.x86_64
BuildRequires: gawk = 220.127.116.11.fc10.x86_64
BuildRequires: gcc-gfortran = 18.104.22.168.x86_64
BuildRequires: gettext = 0.17.8.fc10.x86_64
BuildRequires: glibc-common = 22.214.171.124.x86_64
BuildRequires: grep = 2.5.1a.61.fc10.x86_64
BuildRequires: gzip = 126.96.36.199.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++ = 188.8.131.52.fc9.x86_64
BuildRequires: mingw32-gcc = 184.108.40.206.fc9.x86_64
BuildRequires: mingw32-gettext = 0.17.6.fc9.noarch
BuildRequires: mingw32-iconv = 1.12.4.fc9.noarch
BuildRequires: mingw32-runtime = 220.127.116.11.fc9.noarch
BuildRequires: mingw32-w32api = 3.12.1.fc9.noarch
BuildRequires: net-tools = 1.60.91.fc10.x86_64
BuildRequires: sed = 18.104.22.168.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.
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.
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.
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:
We have a tenative (local) srpm, and intend with this announcement to
put the boost upgrade in the queue for F11. Consider yourself notified,
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.
The previous maintainer of emacs and lsscsi has asked me to find new
maintainers for these packages. He is no longer able to devote any time
to Fedora and had unsubscribed from lists a while ago while on vacation.
If you are interested in taking over one or both of these packages in
Fedora, please contact me.
Fedora -- Freedom² is a feature!