On Tue, Jul 08, 2008 at 12:17:47PM -0400, Frank Ch. Eigler wrote:
>
> "Richard W.M. Jones" <rjones@redhat.com> writes:
>
> > [...] I said it's not a problem for the MinGW SIG (ie. Fedora), but
> > it is a problem for the libvirt project.
>
> So it is that important to you to permit someone to distribute
> proprietary libvirt-based applications that run *on windows*?
> Is providing this sort of enablement important to Fedora?

IMHO, yes. We've had alot of feedback that people really like the libraries
we provide for managing virtualized Fedora / Linux hosts, and they'd like
to make use of our libraries in their existing closed source management
tools. Not having Windows support for our management tools is a show-stopper
for many potential users though.

So by providing libvirt client bits on Windows we enable more people to
deploy & manage virtualized Fedora hosts. This will increase the number
of people using Fedora and virtualization which is a good thing for the
Fedora community. It also helps the libvirt community which becomes a
defacto standard open source managment API across platforms, at a time
when all other virt vendors would rather their users were locked into
proprietry custom APIs & tools.

If we only provided GPL'd libraries for libvirt on Windows they simply
won't use libvirt or Fedora virtualization, pushing more people towards
closed source virt solutuons like VMWare

Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Op dinsdag 08-07-2008 om 16:13 uur [tijdzone +0100], schreef Richard
W.M. Jones:
> I think it's reasonable to have a 'sample' spec file snippet for
> existing maintainers to use & modify when they feel they want to add
> MinGW support. I'll give it a go with some existing libraries to see
> what they would look like.

First of all, great initiative!
This sure looks interesting for me, because the packages I develop also
need to run on Win32 environments and I hate to keep rebooting.

I've just read your draft packaging guidelines and I think there also
should be a pkg-config specific part. A lot of libraries use pkg-config
nowadays. In order to prevent autoconf/configure scripts from using the
host system headers and libraries, some additional preparation is
required.

The man-page of pkg-config says the following with regard to overriding
the default search path:

"By default, pkg-config looks in the directory prefix/lib/pkgconfig for
these files; it will also look in the colon-separated (on Windows,
semicolon-separated) list of directories specified by the
PKG_CONFIG_PATH environment variable."

So if a mingw package requires a library which uses pkg-config, the spec
file should contain 'PKG_CONFIG_PATH=
%{_prefix}/i686-pc-mingw32/sys-root/mingw/lib/pkgconfig' right before
calling the ./configure script.

However, there's still another potential problem: according to the
man-page of pkg-config, the default path (prefix/lib/pkgconfig) is also
searched, which still can lead to conflicts. Maybe it is an idea to
patch pkg-config so that depending on some environment variable the
default path isn't searched.

Regards,

Erik van Pienbroek


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

OK, here is a 'fragment'.

What I have done is to take the current GnuTLS package from Fedora
Rawhide and patch it so that it generates a mingw-gnutls subpackage.
Attached to this message is the patch, and below I discuss the various
parts of the patch.

If you want to see the original vs modified spec files, go here:

http://hg.et.redhat.com/misc/fedora-mingw--devel?cmd=manifest;manifest=91a808c59de63589367c7b d9750da1fca342c529;path=/gnutls-fragment/

Discussion of the patch follows below.

Rich.

+%define __os_install_post /usr/lib/rpm/brp-compress %{nil}

Using ordinary /usr/bin/strip on MinGW lib*.a files not only doesn't
work, but actually corrupts the files. Therefore we must disable
stripping. I'd love to know how to force RPM to either ignore files
in certain directories, or to call the correct strip binary on them.
The original SRPMs that I was working with contained a very long and
hairy bit of code which apparently did this, but I wasn't daring
enough to include it.

+%package -n mingw-gnutls
+Summary: MinGW Windows cross-compile of %{name} package
+Group: Development/Libraries
+
+BuildRequires: mingw-gcc
+BuildRequires: mingw-binutils
+BuildRequires: mingw-libgpg-error
+BuildRequires: mingw-libgcrypt
+
+Requires: mingw-runtime
+Requires: mingw-libgpg-error
+Requires: mingw-libgcrypt

Main package definition. Note that we don't have any automatic
find-requires working at the moment, so we need to define dependent
packages explicitly.

%build
+mkdir build
+pushd build
+echo '../configure "$@"' > configure; chmod +x configure
%configure --with-libtasn1-prefix=%{_prefix}
--with-included-libcfg
--disable-srp-authentication
make
+popd
+
+mkdir i686-pc-mingw32
+pushd i686-pc-mingw32
+CFLAGS="$RPM_OPT_FLAGS -fno-stack-protector"
+../configure
+ --build=%_build
+ --host=i686-pc-mingw32
+ --prefix=%{_prefix}/i686-pc-mingw32/sys-root/mingw
+ --disable-cxx
+ --with-included-libtasn1
+ --with-included-libcfg
+ --disable-srp-authentication
+make
+popd

I've split the build by configuring & building in two subdirectories,
ie. the general pattern is:

pushd build
../configure &c
popd
pushd i686-pc-mingw32
../configure --host=i686-pc-mingw32 &c
popd

Note the hack to make %configure work in a subdirectory. Any easier way?

+%files -n mingw-gnutls
+%defattr(-,root,root)
+%{_prefix}/i686-pc-mingw32/sys-root/mingw/bin/*
+%{_prefix}/i686-pc-mingw32/sys-root/mingw/lib/*
+%{_prefix}/i686-pc-mingw32/sys-root/mingw/include/*
+%{_prefix}/i686-pc-mingw32/sys-root/mingw/share/aclocal/*
+%{_prefix}/i686-pc-mingw32/sys-root/mingw/share/info/*
+%{_prefix}/i686-pc-mingw32/sys-root/mingw/share/man/man1/*
+%{_prefix}/i686-pc-mingw32/sys-root/mingw/share/man/man3/*

This is the filelist for the mingw-specific files.


--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
--- gnutls-original.spec 2008-07-08 18:45:02.000000000 +0100
+++ gnutls.spec 2008-07-08 20:08:19.000000000 +0100
@@ -1,7 +1,12 @@
+# XXX This prevents binaries from being stripped. Using ordinary 'strip'
+# on a MinGW library actually corrupts the library, hence we must disable
+# this action. However we would still like Fedora binaries to be stripped.
+%define __os_install_post /usr/lib/rpm/brp-compress %{nil}
+
Summary: A TLS protocol implementation
Name: gnutls
Version: 2.4.1
-Release: 1%{?dist}
+Release: 2%{?dist}
# The libgnutls library is LGPLv2+, utilities and remaining libraries are GPLv3+
License: GPLv3+ and LGPLv2+
Group: System Environment/Libraries
@@ -33,6 +38,20 @@
Group: Applications/System
Requires: %{name} = %{version}-%{release}

+%package -n mingw-gnutls
+Summary: MinGW Windows cross-compile of %{name} package
+Group: Development/Libraries
+
+BuildRequires: mingw-gcc
+BuildRequires: mingw-binutils
+BuildRequires: mingw-libgpg-error
+BuildRequires: mingw-libgcrypt
+
+Requires: mingw-runtime
+Requires: mingw-libgpg-error
+Requires: mingw-libgcrypt
+
+
%description
GnuTLS is a project that aims to develop a library which provides a secure
layer, over a reliable transport layer. Currently the GnuTLS library implements
@@ -52,6 +71,14 @@
This package contains command line TLS client and server and certificate
manipulation tools.

+%description -n mingw-gnutls
+GnuTLS is a project that aims to develop a library which provides a secure
+layer, over a reliable transport layer. Currently the GnuTLS library implements
+the proposed standards by the IETF's TLS working group.
+This package contains a MinGW Windows cross-compiled library so that
+you can build programs that depend on GnuTLS library for Windows from
+a Fedora host.
+
%prep
%setup -q
%patch1 -p1 -b .nosrp
@@ -61,13 +88,32 @@
done

%build
+mkdir build
+pushd build
+echo '../configure "$@"' > configure; chmod +x configure
%configure --with-libtasn1-prefix=%{_prefix}
--with-included-libcfg
--disable-srp-authentication
make
+popd
+
+mkdir i686-pc-mingw32
+pushd i686-pc-mingw32
+CFLAGS="$RPM_OPT_FLAGS -fno-stack-protector"
+../configure
+ --build=%_build
+ --host=i686-pc-mingw32
+ --prefix=%{_prefix}/i686-pc-mingw32/sys-root/mingw
+ --disable-cxx
+ --with-included-libtasn1
+ --with-included-libcfg
+ --disable-srp-authentication
+make
+popd

%install
rm -fr $RPM_BUILD_ROOT
+pushd build
%makeinstall
rm -f $RPM_BUILD_ROOT%{_bindir}/srptool
rm -f $RPM_BUILD_ROOT%{_bindir}/gnutls-srpcrypt
@@ -78,9 +124,16 @@
rm -f $RPM_BUILD_ROOT%{_infodir}/dir
rm -f $RPM_BUILD_ROOT%{_libdir}/*.la
%find_lang %{name}
+popd
+
+pushd i686-pc-mingw32
+make DESTDIR=$RPM_BUILD_ROOT install
+popd

%check
+pushd build
make check
+popd

%clean
rm -fr $RPM_BUILD_ROOT
@@ -99,7 +152,7 @@
/sbin/install-info --delete %{_infodir}/gnutls.info.gz %{_infodir}/dir || :
fi

-%files -f %{name}.lang
+%files -f build/%{name}.lang
%defattr(-,root,root,-)
%{_libdir}/*.so.*
%doc COPYING COPYING.LIB README AUTHORS
@@ -122,7 +175,20 @@
%{_bindir}/gnutls*
%{_mandir}/man1/*

+%files -n mingw-gnutls
+%defattr(-,root,root)
+%{_prefix}/i686-pc-mingw32/sys-root/mingw/bin/*
+%{_prefix}/i686-pc-mingw32/sys-root/mingw/lib/*
+%{_prefix}/i686-pc-mingw32/sys-root/mingw/include/*
+%{_prefix}/i686-pc-mingw32/sys-root/mingw/share/aclocal/*
+%{_prefix}/i686-pc-mingw32/sys-root/mingw/share/info/*
+%{_prefix}/i686-pc-mingw32/sys-root/mingw/share/man/man1/*
+%{_prefix}/i686-pc-mingw32/sys-root/mingw/share/man/man3/*
+
%changelog
+* Tue Jul 8 2008 Richard W.M. Jones <rjones@redhat.com> 2.4.1-2
+- Build mingw-gnutls subpackage.
+
* Tue Jul 1 2008 Tomas Mraz <tmraz@redhat.com> 2.4.1-1
- new upstream version
- correct the license tag
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, Jul 08, 2008 at 09:09:05PM +0200, Erik van Pienbroek wrote:
> I've just read your draft packaging guidelines and I think there also
> should be a pkg-config specific part. A lot of libraries use pkg-config
> nowadays. In order to prevent autoconf/configure scripts from using the
> host system headers and libraries, some additional preparation is
> required.
[...]

Yes, I think you're right about this. A good test case will be
libvirt because at the moment the configure script in libvirt doesn't
find the correct libxml2. (It finds the system libxml2, not the MinGW
one).

Rich.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 59 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Richard W.M. Jones wrote:

On Tue, Jul 08, 2008 at 02:30:10PM +0100, Daniel P. Berrange wrote:

On Mon, Jul 07, 2008 at 10:15:54PM +0100, Richard W.M. Jones wrote:

I've got a self-building, mostly working set of Fedora packages for
the MinGW cross-compiler (no optional libraries yet). You can get the
spec files and instructions by doing:

hg clone http://hg.et.redhat.com/misc/fedora-mingw--devel

What primarily concerns me is that plan around keeping this in sync
with patches/updates to the main gcc, binutils, libpng, libgcrypt,
gnutls, etc RPMS already in Fedora.

The idea of maintaining 2 near identical specs & builds for all these
packages isn't that nice, particularly since many of these are security
sensitive packages


So there's a bit of confusion going around, partly my own.

Mingw-binutils (https://bugzilla.redhat.com/show_bug.cgi?id=454408)
starts with a forked version of binutils maintained by mingw. They
have their own release schedule for this so I'm not sure how viable it
is to have a single binutils SPEC file generating both the normal
binutils and a 'binutils-mingw' subpackage. (Ignoring for now whether
or not the Fedora binutils maintainer is even interested in this).

Mingw-gcc (https://bugzilla.redhat.com/show_bug.cgi?id=454410) starts
from plain gcc 4.3.1 source, so combining these into Fedora's gcc
package might be more hopeful. However there are some nasty
dependencies (mingw-runtime and mingw-w32api, neither of which can be
built ab initio because of circular dependencies) and I suspect that
any time there is any sort of mingw related trouble with this package,
the gcc-mingw subpackage will be the first to be dropped. I don't
want this.

As for the remainder we get into asking question like -- should we
generate the mingw-gnutls library (as an example) from the main gnutls
SPEC file? There are going to be dozens of such libraries and we'll
have to coordinate with a large number of existing Fedora contributors
to make this happen.


i hope you see these packages:
http://mirzam.it.vu.nl/mingw/
i create packages based on these rpms for rhel too and used them for
years. packages here:

http://www.lfarkas.org/linux/packages/centos/5/

--
Levente "Si vis pacem para bellum!"

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, Jul 08, 2008 at 08:32:26PM +0100, Richard W.M. Jones wrote:
>
> +%define __os_install_post /usr/lib/rpm/brp-compress %{nil}
>
> Using ordinary /usr/bin/strip on MinGW lib*.a files not only doesn't
> work, but actually corrupts the files. Therefore we must disable
> stripping. I'd love to know how to force RPM to either ignore files
> in certain directories, or to call the correct strip binary on them.
> The original SRPMs that I was working with contained a very long and
> hairy bit of code which apparently did this, but I wasn't daring
> enough to include it.

I think that %define will affect the main RPM, as well as mingw
sub-RPM, so we can't simply set it to %{nil}. Couple of options
that I see

- Find out what's wrong with strip & fix it
- Modify the default brp-compress script to avoid mingw files
- Create a wrapper around default brp-compress script to filer
mingw files and %define __os_install_post to use that


> +BuildRequires: mingw-gcc
> +BuildRequires: mingw-binutils
> +BuildRequires: mingw-libgpg-error
> +BuildRequires: mingw-libgcrypt
> +
> +Requires: mingw-runtime
> +Requires: mingw-libgpg-error
> +Requires: mingw-libgcrypt
>
> Main package definition. Note that we don't have any automatic
> find-requires working at the moment, so we need to define dependent
> packages explicitly.

Doesn't the default ELF find-rquires already discover these ? I thought
it would look for all ELF files no matter where they were installed ?

> I've split the build by configuring & building in two subdirectories,
> ie. the general pattern is:
>
> pushd build
> ../configure &c
> popd
> pushd i686-pc-mingw32
> ../configure --host=i686-pc-mingw32 &c
> popd
>
> Note the hack to make %configure work in a subdirectory. Any easier way?

While this works for GNUTLS I don't think we can assume that all libs
we want will support VPATH builds. IIRC the way the kernel deals with
this is to have a completely separate source tree per build target.

We could do this by changing

%setup

to

%setup -c

So the sources end up in rpm/BUILD/gnutls-2.4.1/gnutls-2.4.1

Then in the %build seciton we can copy the source tree for
mingw

cp -a %{name}-%{version} %{name}-%{version}-mingw
pushd %{name}-%{version}
%configure
make
popd
pushd %{name}-%{version}
%configure --host=i686-pc-mingw32
make
popd

Takes extra disk space during the build of course,but none of the things
we're looking at are particularly large.


Oh, we probably also want to have a %define with_mingw at the top of
the spec files to allow the mingw sub-RPM to be turned on/off easily.
This will speed up build times during regular package maintainer work.

Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Thu, Jul 10, 2008 at 12:05:02PM +0100, Daniel P. Berrange wrote:
> On Tue, Jul 08, 2008 at 08:32:26PM +0100, Richard W.M. Jones wrote:
> >
> > +%define __os_install_post /usr/lib/rpm/brp-compress %{nil}
> >
> > Using ordinary /usr/bin/strip on MinGW lib*.a files not only doesn't
> > work, but actually corrupts the files. Therefore we must disable
> > stripping. I'd love to know how to force RPM to either ignore files
> > in certain directories, or to call the correct strip binary on them.
> > The original SRPMs that I was working with contained a very long and
> > hairy bit of code which apparently did this, but I wasn't daring
> > enough to include it.
>
> I think that %define will affect the main RPM, as well as mingw
> sub-RPM, so we can't simply set it to %{nil}. Couple of options
> that I see
>
> - Find out what's wrong with strip & fix it
> - Modify the default brp-compress script to avoid mingw files
> - Create a wrapper around default brp-compress script to filer
> mingw files and %define __os_install_post to use that

The original RPMs I'm working with do the latter. Very complicated
but I'll see if it can be simplified somehow :-(

> > +BuildRequires: mingw-gcc
> > +BuildRequires: mingw-binutils
> > +BuildRequires: mingw-libgpg-error
> > +BuildRequires: mingw-libgcrypt
> > +
> > +Requires: mingw-runtime
> > +Requires: mingw-libgpg-error
> > +Requires: mingw-libgcrypt
> >
> > Main package definition. Note that we don't have any automatic
> > find-requires working at the moment, so we need to define dependent
> > packages explicitly.
>
> Doesn't the default ELF find-rquires already discover these ? I thought
> it would look for all ELF files no matter where they were installed ?

They're not ELF binaries, they are Windows binaries which are a
perverted type of COFF. I can't see how one would discover
requirements without specific Windows binutils being installed.
Probably need to have custom find-requires/find-provides as we do with
OCaml.

> > I've split the build by configuring & building in two subdirectories,
> > ie. the general pattern is:
> >
> > pushd build
> > ../configure &c
> > popd
> > pushd i686-pc-mingw32
> > ../configure --host=i686-pc-mingw32 &c
> > popd
> >
> > Note the hack to make %configure work in a subdirectory. Any easier way?
>
> While this works for GNUTLS I don't think we can assume that all libs
> we want will support VPATH builds. IIRC the way the kernel deals with
> this is to have a completely separate source tree per build target.
>
> We could do this by changing
>
> %setup
>
> to
>
> %setup -c
>
> So the sources end up in rpm/BUILD/gnutls-2.4.1/gnutls-2.4.1

OK, fair enough ...

> Oh, we probably also want to have a %define with_mingw at the top of
> the spec files to allow the mingw sub-RPM to be turned on/off easily.
> This will speed up build times during regular package maintainer work.

Yup.

Rich.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 59 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Fri, 2008-07-11 at 09:48 +0100, Richard W.M. Jones wrote:
> On Thu, Jul 10, 2008 at 12:05:02PM +0100, Daniel P. Berrange wrote:
> > On Tue, Jul 08, 2008 at 08:32:26PM +0100, Richard W.M. Jones wrote:
> > >
> > > +%define __os_install_post /usr/lib/rpm/brp-compress %{nil}
> > >
> > > Using ordinary /usr/bin/strip on MinGW lib*.a files not only doesn't
> > > work, but actually corrupts the files.

My hack to work around this issues (and others related to brp-* stuff)
is this hack:

...
%define _use_internal_dependency_generator 0
...
%build
...
%install
...
# Extract %%__os_install_post into os_install_post~
cat << EOF > os_install_post~
%__os_install_post
EOF

# Generate customized brp-*scripts
cat os_install_post~ | while read a x y; do
case $a in
# Prevent brp-strip* from trying to handle foreign binaries
*/brp-strip*)
b=$(basename $a)
sed -e 's,find $RPM_BUILD_ROOT,find $RPM_BUILD_ROOT%_bindir $RPM_BUILD_ROOT%_libexecdir,' $a > $b
chmod a+x $b
;;
# Fix up brp-compress to handle %%_prefix != /usr
*/brp-compress*)
b=$(basename $a)
sed -e 's,./usr/,.%{_prefix}/,g' < $a > $b
chmod a+x $b
;;
esac
done

sed -e 's,^[ ]*/usr/lib/rpm.*/brp-strip,./brp-strip,'
-e 's,^[ ]*/usr/lib/rpm.*/brp-compress,./brp-compress,'
< os_install_post~ > os_install_post
%define __os_install_post . ./os_install_post


cat << EOF > %{_builddir}/%{name}-%{gcc_rpmvers}/find-provides
#!/bin/sh
grep -E -v '^${RPM_BUILD_ROOT}%{_exec_prefix}/%tool_target/(lib|include|sys-root)'
| grep -v '^${RPM_BUILD_ROOT}%{gcclib}/%tool_target/' | %__find_provides
EOF
chmod +x %{_builddir}/%{name}-%{gcc_rpmvers}/find-provides
%define __find_provides %{_builddir}/%{name}-%{gcc_rpmvers}/find-provides


cat << EOF > %{_builddir}/%{name}-%{gcc_rpmvers}/find-requires
#!/bin/sh
grep -E -v '^${RPM_BUILD_ROOT}%{_exec_prefix}/%tool_target/(lib|include|sys-root)'
| grep -v '^${RPM_BUILD_ROOT}%{gcclib}/%tool_target/' | %__find_requires
EOF
chmod +x %{_builddir}/%{name}-%{gcc_rpmvers}/find-requires
%define __find_requires %{_builddir}/%{name}-%{gcc_rpmvers}/find-requires


I know, this looks ugly (and it is), but guess you can get the idea:
Dynamically hackuping rpm's brp-* and find-* scripts to not mistreat
files. Works quite well for me, even on non-Fedora-distros and
non-RH-distros.


Ralf


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Fri, Jul 11, 2008 at 11:37:16AM +0200, Ralf Corsepius wrote:
> I know, this looks ugly (and it is), but guess you can get the idea:
> Dynamically hackuping rpm's brp-* and find-* scripts to not mistreat
> files. Works quite well for me, even on non-Fedora-distros and
> non-RH-distros.

Yes, I was looking at this from your(?) original SRPMs. I'm going to
look at if we can simplify this and/or centralize those scripts into
one place.

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Fri, 2008-07-11 at 10:41 +0100, Richard W.M. Jones wrote:
> On Fri, Jul 11, 2008 at 11:37:16AM +0200, Ralf Corsepius wrote:
> > I know, this looks ugly (and it is), but guess you can get the idea:
> > Dynamically hackuping rpm's brp-* and find-* scripts to not mistreat
> > files. Works quite well for me, even on non-Fedora-distros and
> > non-RH-distros.
>
> Yes, I was looking at this from your(?) original SRPMs.

My cross-toolchain rpms can be found inside of the src.rpms below
ftp://www.rtems.org/pub/rtems/linux

BTW: These specs are generated and therefore are not necessarily easily
human readable.

> I'm going to
> look at if we can simplify this and/or centralize those scripts into
> one place.
My package are supposed to be add-on packages to distros (Fedora,
CentOS, SuSE) and therefore support installation to outside of /usr (I
use /opt/<somewhere>)

Therefore, some of the ugliness can be removed when only considering
installation to /usr (e.g. man-page compression (brp-compress).

Apart of this aspect, I am not aware about much that could be removed.

Ralf


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list