[PATCH] Split out e2fsprogs sublibraries
by Richard W.M. Jones
Eric,
I would like to propose that e2fsprogs generate four subpackages for
the independent libraries that it contains. These four libraries are
used by other packages that don't need the whole of e2fsprogs-devel
(eg. krb5_workstation uses libss, qpid uses libuuid, and many programs
use libcom_err).
Our specific use case is to help with ongoing work porting libraries
to MinGW (http://fedoraproject.org/wiki/MinGW) where we would prefer
to package mingw32-libuuid for mingw32-qpidc without needing to port
the whole of e2fsprogs.
I looked at Debian's package, and would like to propose a split along
the same lines:
http://packages.debian.org/source/lenny/e2fsprogs
Despite the apparent complexity, there are only really four
subpackages. For the Fedora package we would create:
libblkid libblkid-devel
libcom_err libcom_err-devel [note 1]
libss libss-devel
libuuid libuuid-devel
There are no conflicting package names in Fedora at the moment, except
for the similarly named libss7 (a library implementing Signalling
System 7 telephone switching protocol).
I have attached a patch against Rawhide which does the above split. I
set up the dependencies so there should be no loss of functionality
for users who install just e2fsprogs or e2fsprogs-devel.
What remains is to advertize the split on fedora-devel-list and
encourage package maintainers to replace:
BuildRequires: e2fsprogs-devel
with
BuildRequires: lib<uuid|ss|blkid|com_err>-devel
where appropriate.
Please let me know what you think.
Rich.
[1] http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Common_Character...
--
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
mingw-w64 proposed changes to the triplet
by Richard W.M. Jones
If you have any comments on this, best to take them up with Kai on
#mingw-w64 on OFTC.
Rich.
<ktietz> morning
<ktietz> we are currently in the decision finding about an extended
target triplet for mingw-w64.
<ktietz> there are at the moment three different approaches. All have
their advantages and disadvantages.
<ktietz> first is introducing an triplet with new OS part, e.g
something like <cpu>-pc-mingw64
<ktietz> second, is to add configure checks about probing the used
target runtime headers to enable our additional features
<ktietz> and the third is, to use the vendor key in triplet,
e.g. <cpu>-ms-mingw32*
<ktietz> so I would like to hear your opinion about this.
<ktietz> this step is getting necessary, because we want to support
multilib, and -municode feature. But mingw.org can't follow us in this
set at the moment
<ktietz> all those features should be available for 32-bit and 64-bit
targeting. So we have to split out here those incompatible
features. On the other hand we want still support a compatiblity mode
with the old triplet, which simply doesn't have those new features in
gcc
<rjones> not sure what to say except (1) we use the triplet as part of
the directory structure /usr/x86_64-pc-mingw32/ for example, (2)
changing it is extremely time-consuming, so don't change it more than
you need to, and (3) our policy is to follow upstream, ie. you
<ktietz> this was the reason to use here the vendor part of the key
<ktietz> so you can build in the compatibility mode to mingw.org and
if you use it with ms or w64 (the vendor name isn't fix until now) to
build with new features
<ktietz> IMHO this is the solution with most less negative
side-effects
<ktietz> most less=less
<rjones> ktietz, we haven't rolled out any mingw-w64 packages
officially yet, that's in the plan for our next cycle, starting
may/june. All we have at the moment are unofficial/experimental
packages, so backwards compatibility isn't much of a concern.
<ktietz> ok, the idea here was, that we do not move to far away from
mingw.org
<ktietz> but we can fix for example the mingw directory issue, doing
multilib without the need of interfering with mingw.org, and are able
to add features like unicode support
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 75 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
15 years
additional Qt libraries
by Kalev Lember
Hello,
I have attached a patch that enables building of QtOpenGL, QtScript,
QtScriptTools, and QtXmlPatterns in mingw32-qt package. Could you update
the package in rawhide and include this patch?
Spec file: http://www.smartlink.ee/~kalev/mingw32-qt.spec
Source RPM: http://www.smartlink.ee/~kalev/mingw32-qt-4.5.0-4.fc11.src.rpm
Koji scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1268407
--
Kalev Lember
--- mingw32-qt.spec-orig 2009-03-16 04:34:11.000000000 +0200
+++ mingw32-qt.spec 2009-03-31 20:48:46.000000000 +0300
@@ -13,11 +13,11 @@
# from the native Fedora package. The reason is so that we can
# set the default include and library paths correctly.
-%define subdirs src/corelib src/xml src/network src/gui src/winmain src/svg src/sql src/qt3support
+%define subdirs src/corelib src/network src/xml src/xmlpatterns src/gui src/winmain src/svg src/sql src/qt3support src/opengl src/script src/scripttools
Name: mingw32-qt
Version: 4.5.0
-Release: 3%{?dist}
+Release: 4%{?dist}
Summary: Qt for Windows
License: GPLv3 with exceptions or LGPLv2 with exceptions
@@ -176,47 +176,71 @@
%defattr(-,root,root)
%doc configure.output
%doc LICENSE.GPL3 LICENSE.LGPL LGPL_EXCEPTION.txt KNOWN.ISSUES README
-%{_mingw32_bindir}/QtCore4.dll
-%{_mingw32_bindir}/QtGui4.dll
-%{_mingw32_bindir}/QtNetwork4.dll
-%{_mingw32_bindir}/QtXml4.dll
-%{_mingw32_bindir}/QtSvg4.dll
-%{_mingw32_bindir}/QtSql4.dll
%{_mingw32_bindir}/Qt3Support4.dll
+%{_mingw32_bindir}/Qt3Supportd4.dll
+%{_mingw32_bindir}/QtCore4.dll
%{_mingw32_bindir}/QtCored4.dll
+%{_mingw32_bindir}/QtGui4.dll
%{_mingw32_bindir}/QtGuid4.dll
+%{_mingw32_bindir}/QtNetwork4.dll
%{_mingw32_bindir}/QtNetworkd4.dll
-%{_mingw32_bindir}/QtXmld4.dll
-%{_mingw32_bindir}/QtSvgd4.dll
+%{_mingw32_bindir}/QtOpenGL4.dll
+%{_mingw32_bindir}/QtOpenGLd4.dll
+%{_mingw32_bindir}/QtScript4.dll
+%{_mingw32_bindir}/QtScriptd4.dll
+%{_mingw32_bindir}/QtScriptTools4.dll
+%{_mingw32_bindir}/QtScriptToolsd4.dll
+%{_mingw32_bindir}/QtSql4.dll
%{_mingw32_bindir}/QtSqld4.dll
-%{_mingw32_bindir}/Qt3Supportd4.dll
-%{_mingw32_libdir}/libQtCore4.a
-%{_mingw32_libdir}/libQtGui4.a
-%{_mingw32_libdir}/libQtNetwork4.a
-%{_mingw32_libdir}/libQtXml4.a
-%{_mingw32_libdir}/libQtSvg4.a
-%{_mingw32_libdir}/libQtSql4.a
+%{_mingw32_bindir}/QtSvg4.dll
+%{_mingw32_bindir}/QtSvgd4.dll
+%{_mingw32_bindir}/QtXml4.dll
+%{_mingw32_bindir}/QtXmld4.dll
+%{_mingw32_bindir}/QtXmlPatterns4.dll
+%{_mingw32_bindir}/QtXmlPatternsd4.dll
%{_mingw32_libdir}/libQt3Support4.a
-%{_mingw32_libdir}/libqtmain.a
+%{_mingw32_libdir}/libQt3Supportd4.a
+%{_mingw32_libdir}/libQtCore4.a
%{_mingw32_libdir}/libQtCored4.a
+%{_mingw32_libdir}/libQtGui4.a
%{_mingw32_libdir}/libQtGuid4.a
+%{_mingw32_libdir}/libqtmain.a
+%{_mingw32_libdir}/libqtmaind.a
+%{_mingw32_libdir}/libQtNetwork4.a
%{_mingw32_libdir}/libQtNetworkd4.a
-%{_mingw32_libdir}/libQtXmld4.a
-%{_mingw32_libdir}/libQtSvgd4.a
+%{_mingw32_libdir}/libQtOpenGL4.a
+%{_mingw32_libdir}/libQtOpenGLd4.a
+%{_mingw32_libdir}/libQtScript4.a
+%{_mingw32_libdir}/libQtScriptd4.a
+%{_mingw32_libdir}/libQtScriptTools4.a
+%{_mingw32_libdir}/libQtScriptToolsd4.a
+%{_mingw32_libdir}/libQtSql4.a
%{_mingw32_libdir}/libQtSqld4.a
-%{_mingw32_libdir}/libQt3Supportd4.a
-%{_mingw32_libdir}/libqtmaind.a
+%{_mingw32_libdir}/libQtSvg4.a
+%{_mingw32_libdir}/libQtSvgd4.a
+%{_mingw32_libdir}/libQtXml4.a
+%{_mingw32_libdir}/libQtXmld4.a
+%{_mingw32_libdir}/libQtXmlPatterns4.a
+%{_mingw32_libdir}/libQtXmlPatternsd4.a
%{_mingw32_includedir}/Qt/
+%{_mingw32_includedir}/Qt3Support/
%{_mingw32_includedir}/QtCore/
%{_mingw32_includedir}/QtGui/
%{_mingw32_includedir}/QtNetwork/
-%{_mingw32_includedir}/QtXml/
-%{_mingw32_includedir}/QtSvg/
+%{_mingw32_includedir}/QtOpenGL/
+%{_mingw32_includedir}/QtScript/
+%{_mingw32_includedir}/QtScriptTools/
%{_mingw32_includedir}/QtSql/
-%{_mingw32_includedir}/Qt3Support/
+%{_mingw32_includedir}/QtSvg/
+%{_mingw32_includedir}/QtXml/
+%{_mingw32_includedir}/QtXmlPatterns/
%changelog
+* Tue Mar 31 2009 Kalev Lember <kalev(a)smartlink.ee> - 4.5.0-4
+- Enable QtOpenGL, QtScript, QtScriptTools, and QtXmlPatterns.
+- Sort files section for readability.
+
* Sun Mar 16 2009 Thomas Sailer <t.sailer(a)alumni.ethz.ch> - 4.5.0-3
- moved cross compiler qmake setup files into separate package
to keep this package noarch
15 years
libmp4v2: int types + network headers
by Zoltan Seress
Hi,
Building libmp4v2 I found that some sources would like to use non-standard
types like u_int32_t, u_int64_t and u_int8_t, but there are no typedef-s
anywhere. If I replace them in the mp4 headers with uint32_t ... it seems to
be good. ( uint32_t and the others are defined in
/usr/i686-pc-mingw32/sys-root/mingw/include/stdint.h. ). But I guess this is
not the right solution, becouse other packages maybe involved in this issue.
Or which basic mingw32 package should be edited to have these new typedefs?
Another question:
There are some includes, for example /arpa/inet.h, which are not in mingw.
Is there a specific header which should be used instead?
--
Zoltan Seress
15 years