hi, while i try to rebuild mingw32-libxml2 i've got this error: ------------------------------------------------------- Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/mingw32-libxml2-2.7.2-3-root-lfarkas error: Installed (but unpackaged) file(s) found: /usr/i686-pc-mingw32/sys-root/mingw/man/man1/xml2-config.1 /usr/i686-pc-mingw32/sys-root/mingw/man/man1/xmlcatalog.1 /usr/i686-pc-mingw32/sys-root/mingw/man/man1/xmllint.1 /usr/i686-pc-mingw32/sys-root/mingw/man/man3/libxml.3
RPM build errors: File listed twice: /usr/i686-pc-mingw32/sys-root/mingw/lib/pkgconfig/libxml-2.0.pc Installed (but unpackaged) file(s) found: /usr/i686-pc-mingw32/sys-root/mingw/man/man1/xml2-config.1 /usr/i686-pc-mingw32/sys-root/mingw/man/man1/xmlcatalog.1 /usr/i686-pc-mingw32/sys-root/mingw/man/man1/xmllint.1 /usr/i686-pc-mingw32/sys-root/mingw/man/man3/libxml.3 ------------------------------------------------------- this's because on fedora man pages in /usr/share/man while on rhel/centos (and older fedora releases) it was under /usr/man.
of course since we delete all man and info pages i can simple delete these directories too. but the question why this happened? because it's hardcoded into mingw32-filesystem's /etc/rpm/macros.mingw32. wouldn't be these macros: ------------------------------------------------------- %_mingw32_sysroot %{_prefix}/i686-pc-mingw32/sys-root %_mingw32_prefix %{_mingw32_sysroot}/mingw %_mingw32_bindir %{_mingw32_prefix}/bin %_mingw32_sbindir %{_mingw32_prefix}/sbin %_mingw32_libdir %{_mingw32_prefix}/lib %_mingw32_libexecdir %{_mingw32_prefix}/libexec %_mingw32_datadir %{_mingw32_prefix}/share %_mingw32_docdir %{_mingw32_prefix}/share/doc %_mingw32_infodir %{_mingw32_prefix}/share/info %_mingw32_mandir %{_mingw32_prefix}/share/man %_mingw32_sysconfdir %{_mingw32_prefix}/etc %_mingw32_includedir %{_mingw32_prefix}/include ------------------------------------------------------- rewritten to something like this: %_mingw32_mandir %{_mingw32_prefix}%_mandir etc.
On Mon, Nov 10, 2008 at 06:24:44PM +0100, Farkas Levente wrote:
this's because on fedora man pages in /usr/share/man while on rhel/centos (and older fedora releases) it was under /usr/man.
Hmm, that sucks ...
of course since we delete all man and info pages i can simple delete these directories too. but the question why this happened? because it's hardcoded into mingw32-filesystem's /etc/rpm/macros.mingw32. wouldn't be these macros:
Probably the right thing to do is to pass the man directory explicitly in configure, ie something like:
%{_mingw32_configure} --mandir=%{_mingw32_mandir}
(or change the actual _mingw32_configure macro to do this automatically, which is analogous to what the base RPM _configure macro does).
In this case it doesn't really matter that much. Just add an extra line into the specfile to nuke the other copy of the manpages ...
Note that we don't really need to keep the same specfile in Fedora and EPEL. It's quite alright if they diverge from each other -- in fact that's expected from the way that Fedora CVS works.
Rich.
Richard W.M. Jones wrote:
On Mon, Nov 10, 2008 at 06:24:44PM +0100, Farkas Levente wrote:
this's because on fedora man pages in /usr/share/man while on rhel/centos (and older fedora releases) it was under /usr/man.
Hmm, that sucks ...
of course since we delete all man and info pages i can simple delete these directories too. but the question why this happened? because it's hardcoded into mingw32-filesystem's /etc/rpm/macros.mingw32. wouldn't be these macros:
Probably the right thing to do is to pass the man directory explicitly in configure, ie something like:
%{_mingw32_configure} --mandir=%{_mingw32_mandir}
(or change the actual _mingw32_configure macro to do this automatically, which is analogous to what the base RPM _configure macro does).
In this case it doesn't really matter that much. Just add an extra line into the specfile to nuke the other copy of the manpages ...
Note that we don't really need to keep the same specfile in Fedora and EPEL. It's quite alright if they diverge from each other -- in fact that's expected from the way that Fedora CVS works.
Rich.
but why not just simple change the paths in the /etc/rpm/macros.mingw32 from ------------------------------------------------------- %_mingw32_mandir %{_mingw32_prefix}/share/man ------------------------------------------------------- to: ------------------------------------------------------- %_mingw32_mandir %{_mingw32_prefix}%{_mandir} ------------------------------------------------------- and all other macros of course? it'll work on both fedora and rhel/centos. what's more these hardcoded paths have other problems too. suppose later would like to create mingw64 and of course info is also bad. what's if happened with sbin: https://fedoraproject.org/wiki/Features/SbinSanity etc...
On Mon, Nov 10, 2008 at 07:03:27PM +0100, Farkas Levente wrote:
%_mingw32_mandir %{_mingw32_prefix}%{_mandir}
That's an idea, but does it work? AFAICT the above would expand to:
/usr/i686-pc-mingw32/sys-root/mingw/usr/share/man
which is incorrect.
Anyhow, there is nothing wrong with having a modified mingw32-filesystem package in the EPEL branch that has the paths changed, if EPEL needs that.
Rich.
Richard W.M. Jones wrote:
On Mon, Nov 10, 2008 at 07:03:27PM +0100, Farkas Levente wrote:
%_mingw32_mandir %{_mingw32_prefix}%{_mandir}
That's an idea, but does it work? AFAICT the above would expand to:
/usr/i686-pc-mingw32/sys-root/mingw/usr/share/man
which is incorrect.
Anyhow, there is nothing wrong with having a modified mingw32-filesystem package in the EPEL branch that has the paths changed, if EPEL needs that.
i already noticed that usr missing from mingw filesystem layout :-(
Richard W.M. Jones wrote:
On Mon, Nov 10, 2008 at 06:24:44PM +0100, Farkas Levente wrote:
this's because on fedora man pages in /usr/share/man while on rhel/centos (and older fedora releases) it was under /usr/man.
Hmm, that sucks ...
of course since we delete all man and info pages i can simple delete these directories too. but the question why this happened? because it's hardcoded into mingw32-filesystem's /etc/rpm/macros.mingw32. wouldn't be these macros:
Probably the right thing to do is to pass the man directory explicitly in configure, ie something like:
%{_mingw32_configure} --mandir=%{_mingw32_mandir}
(or change the actual _mingw32_configure macro to do this automatically, which is analogous to what the base RPM _configure macro does).
another reason what happened if some project not use configure?
On Mon, Nov 10, 2008 at 07:11:00PM +0100, Farkas Levente wrote:
another reason what happened if some project not use configure?
Generally it's a huge pain, eg:
http://hg.et.redhat.com/misc/fedora-mingw--devel/?f=e3979d963923;file=boost/...
Rich.
On Mon, Nov 10, 2008 at 06:24:44PM +0100, Farkas Levente wrote:
this's because on fedora man pages in /usr/share/man while on rhel/centos (and older fedora releases) it was under /usr/man.
I don't know why you're getting the failures, but this statement is wrong. On RHEL man pages are in /usr/share/man just like on Fedora. They've been there for years - certainly RHEL-3, 4, and 5.
Daniel
On Mon, Nov 10, 2008 at 07:28:06PM +0000, Daniel P. Berrange wrote:
On Mon, Nov 10, 2008 at 06:24:44PM +0100, Farkas Levente wrote:
this's because on fedora man pages in /usr/share/man while on rhel/centos (and older fedora releases) it was under /usr/man.
I don't know why you're getting the failures, but this statement is wrong. On RHEL man pages are in /usr/share/man just like on Fedora. They've been there for years - certainly RHEL-3, 4, and 5.
In fact this is a bug in the mingw-filesystem package's definition of the %configure replacement macro. For native builds it is fully defined with
./configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu \ --target=x86_64-redhat-linux-gnu \ --program-prefix= \ --prefix=/usr \ --exec-prefix=/usr \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --sysconfdir=/etc \ --datadir=/usr/share \ --includedir=/usr/include \ --libdir=/usr/lib64 \ --libexecdir=/usr/libexec \ --localstatedir=/var \ --sharedstatedir=/usr/com \ --mandir=/usr/share/man \ --infodir=/usr/share/info
But for mingw,its only defining the --prefix
./configure \ --build=x86_64-unknown-linux-gnu --host=i686-pc-mingw32 --target=i686-pc-mingw32 \ --prefix=/usr/i686-pc-mingw32/sys-root/mingw
We need to fix %_mingw32_configure macro to work the same way as the native macro & thus not rely on unpredictable autoconf defaults which vary depending on what version of autoconf the upstream app happened to generate their configure script with.
Daniel
Daniel P. Berrange wrote:
On Mon, Nov 10, 2008 at 07:28:06PM +0000, Daniel P. Berrange wrote:
On Mon, Nov 10, 2008 at 06:24:44PM +0100, Farkas Levente wrote:
this's because on fedora man pages in /usr/share/man while on rhel/centos (and older fedora releases) it was under /usr/man.
I don't know why you're getting the failures, but this statement is wrong. On RHEL man pages are in /usr/share/man just like on Fedora. They've been there for years - certainly RHEL-3, 4, and 5.
In fact this is a bug in the mingw-filesystem package's definition of the %configure replacement macro. For native builds it is fully defined with
./configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu \ --target=x86_64-redhat-linux-gnu \ --program-prefix= \ --prefix=/usr \ --exec-prefix=/usr \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --sysconfdir=/etc \ --datadir=/usr/share \ --includedir=/usr/include \ --libdir=/usr/lib64 \ --libexecdir=/usr/libexec \ --localstatedir=/var \ --sharedstatedir=/usr/com \ --mandir=/usr/share/man \ --infodir=/usr/share/info
But for mingw,its only defining the --prefix
./configure \ --build=x86_64-unknown-linux-gnu --host=i686-pc-mingw32 --target=i686-pc-mingw32 \ --prefix=/usr/i686-pc-mingw32/sys-root/mingw
We need to fix %_mingw32_configure macro to work the same way as the native macro & thus not rely on unpredictable autoconf defaults which vary depending on what version of autoconf the upstream app happened to generate their configure script with.
ok but which one? there is a mingw32-configure.sh and also there is a %_mingw32_configure macro in /etc/rpm/macros.mingw32. why these two different place, it's redundant. does it really needed?
On Mon, Nov 10, 2008 at 09:54:04PM +0100, Farkas Levente wrote:
Daniel P. Berrange wrote:
On Mon, Nov 10, 2008 at 07:28:06PM +0000, Daniel P. Berrange wrote:
./configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu \ --target=x86_64-redhat-linux-gnu \ --program-prefix= \ --prefix=/usr \ --exec-prefix=/usr \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --sysconfdir=/etc \ --datadir=/usr/share \ --includedir=/usr/include \ --libdir=/usr/lib64 \ --libexecdir=/usr/libexec \ --localstatedir=/var \ --sharedstatedir=/usr/com \ --mandir=/usr/share/man \ --infodir=/usr/share/info
But for mingw,its only defining the --prefix
./configure \ --build=x86_64-unknown-linux-gnu --host=i686-pc-mingw32 --target=i686-pc-mingw32 \ --prefix=/usr/i686-pc-mingw32/sys-root/mingw
We need to fix %_mingw32_configure macro to work the same way as the native macro & thus not rely on unpredictable autoconf defaults which vary depending on what version of autoconf the upstream app happened to generate their configure script with.
ok but which one? there is a mingw32-configure.sh and also there is a %_mingw32_configure macro in /etc/rpm/macros.mingw32. why these two different place, it's redundant. does it really needed?
The 'mingw32-configure.sh' shell script in /usr/bin is for developers who are doing builds outside the context of RPMs. As such it should only set the minimal possible args to cross-compile. It should not apply RPM packaging policy. So we don't need to change mingw32-configure.sh
Just the %_mingw32_ocnfigure macro definition whose purpose is to apply RPM packaging policy such as man page in /usr/share/man
Regards, Daniel
Daniel P. Berrange wrote:
On Mon, Nov 10, 2008 at 09:54:04PM +0100, Farkas Levente wrote:
Daniel P. Berrange wrote:
On Mon, Nov 10, 2008 at 07:28:06PM +0000, Daniel P. Berrange wrote:
./configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu \ --target=x86_64-redhat-linux-gnu \ --program-prefix= \ --prefix=/usr \ --exec-prefix=/usr \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --sysconfdir=/etc \ --datadir=/usr/share \ --includedir=/usr/include \ --libdir=/usr/lib64 \ --libexecdir=/usr/libexec \ --localstatedir=/var \ --sharedstatedir=/usr/com \ --mandir=/usr/share/man \ --infodir=/usr/share/info
But for mingw,its only defining the --prefix
./configure \ --build=x86_64-unknown-linux-gnu --host=i686-pc-mingw32 --target=i686-pc-mingw32 \ --prefix=/usr/i686-pc-mingw32/sys-root/mingw
We need to fix %_mingw32_configure macro to work the same way as the native macro & thus not rely on unpredictable autoconf defaults which vary depending on what version of autoconf the upstream app happened to generate their configure script with.
ok but which one? there is a mingw32-configure.sh and also there is a %_mingw32_configure macro in /etc/rpm/macros.mingw32. why these two different place, it's redundant. does it really needed?
The 'mingw32-configure.sh' shell script in /usr/bin is for developers who are doing builds outside the context of RPMs. As such it should only set the minimal possible args to cross-compile. It should not apply RPM packaging policy. So we don't need to change mingw32-configure.sh
Just the %_mingw32_ocnfigure macro definition whose purpose is to apply RPM packaging policy such as man page in /usr/share/man
i'm attached a rewrite mingw32-macros.mingw32 which works and now libxml2 build. i also added MINGW_CFLAGS and MINGW_CXXFLAGS to be able to overwrite default flags. what's the current policy for packages accepted for fedora? should i open a new bugzilla entry, add to the original review request or post it here?
On Tue, Nov 11, 2008 at 12:13:35AM +0100, Farkas Levente wrote:
i'm attached a rewrite mingw32-macros.mingw32 which works and now libxml2 build.
Please post patches: http://et.redhat.com/~rjones/how-to-supply-code-to-open-source-projects/#pat... It's impossible to review a lump of code.
i also added MINGW_CFLAGS and MINGW_CXXFLAGS to be able to overwrite default flags.
Yes, good idea.
what's the current policy for packages accepted for fedora? should i open a new bugzilla entry, add to the original review request or post it here?
Post a patch on this mailing list.
Get it reviewed and ACKed by at least me & Daniel.
When you get all ACKs you need, make the change to the Fedora CVS package yourself (you have access now).
Rich.
On Mon, Nov 10, 2008 at 09:54:04PM +0100, Farkas Levente wrote:
there is a mingw32-configure.sh and also there is a %_mingw32_configure macro in /etc/rpm/macros.mingw32. why these two different place, it's redundant. does it really needed?
Both files need to be changed.
Rich.
On Tue, Nov 11, 2008 at 10:35:07AM +0000, Richard W.M. Jones wrote:
On Mon, Nov 10, 2008 at 09:54:04PM +0100, Farkas Levente wrote:
there is a mingw32-configure.sh and also there is a %_mingw32_configure macro in /etc/rpm/macros.mingw32. why these two different place, it's redundant. does it really needed?
Both files need to be changed.
Why ? The separate mingw-configure shell script isn't used for the RPM build packaging, and as such shouldn't be applying RPM filesystem layout policy, just the minimal flags to cross-compile suitably. In same way as native %configure overrides everything to apply RPM policy, but plain 'configure' uses the apps default policy.
Daniel
On Tue, Nov 11, 2008 at 10:42:22AM +0000, Daniel P. Berrange wrote:
On Tue, Nov 11, 2008 at 10:35:07AM +0000, Richard W.M. Jones wrote:
On Mon, Nov 10, 2008 at 09:54:04PM +0100, Farkas Levente wrote:
there is a mingw32-configure.sh and also there is a %_mingw32_configure macro in /etc/rpm/macros.mingw32. why these two different place, it's redundant. does it really needed?
Both files need to be changed.
Why ? The separate mingw-configure shell script isn't used for the RPM build packaging, and as such shouldn't be applying RPM filesystem layout policy, just the minimal flags to cross-compile suitably. In same way as native %configure overrides everything to apply RPM policy, but plain 'configure' uses the apps default policy.
Well ... I was hoping to keep them roughly in synch, since I use the mingw32-configure script when initially building/testing, before packaging (ie. before using %{_mingw32_configure}).
I can't see the harm in keeping them (mostly) in synch ...
Having said that, the most important thing is that Levente posts a proposed patch here for review, then we get it agreed on and ACKed, then it can be committed to Fedora.
Rich.
Richard W.M. Jones wrote:
On Tue, Nov 11, 2008 at 10:42:22AM +0000, Daniel P. Berrange wrote:
On Tue, Nov 11, 2008 at 10:35:07AM +0000, Richard W.M. Jones wrote:
On Mon, Nov 10, 2008 at 09:54:04PM +0100, Farkas Levente wrote:
there is a mingw32-configure.sh and also there is a %_mingw32_configure macro in /etc/rpm/macros.mingw32. why these two different place, it's redundant. does it really needed?
Both files need to be changed.
Why ? The separate mingw-configure shell script isn't used for the RPM build packaging, and as such shouldn't be applying RPM filesystem layout policy, just the minimal flags to cross-compile suitably. In same way as native %configure overrides everything to apply RPM policy, but plain 'configure' uses the apps default policy.
Well ... I was hoping to keep them roughly in synch, since I use the mingw32-configure script when initially building/testing, before packaging (ie. before using %{_mingw32_configure}).
I can't see the harm in keeping them (mostly) in synch ...
Having said that, the most important thing is that Levente posts a proposed patch here for review, then we get it agreed on and ACKed, then it can be committed to Fedora.
after sleep a bit i come to the conclusion to rewrite mingw32-filesystem's script a bit: - mingw32-macros.mingw32 for a more detailed configure, - mingw32-macros.mingw32 for a compact cflags, - mingw32-macros.mingw32 for a compact cxxflags, is there any proposed flags for c++ code? - mingw32-macros.mingw32 add makeinstall target - add a generic mingw32-env environment setup into _mingw32_libexecdir which use mingw32-macros.mingw32 and rpmbuild --showrc to use one commong place where all settings take place. so after that only mingw32-macros.mingw32 contains all variable settings - rewrite /usr/bin/mingw32-configure to use the mingw32-env - write a new /usr/bin/mingw32-make which use mingw32-env
i've google around a bit about the sjlj <-> dwarf2 stuff and for me it seems in the current mingw release it's already dwarf2 by default. so i always vote for use the upstream mingw's default. the main problem here is that we've to decided which version to use since if we wanna switch we've to recompile _everything_ as different packages won't be compatible with eachother.
any comments?
On Tue, Nov 11, 2008 at 12:10:20PM +0100, Farkas Levente wrote:
- mingw32-macros.mingw32 for a compact cflags,
Not sure what you mean by 'compact' ... Those CFLAGS aren't just chosen at random, but picked to match as far as possible what is the default for native Fedora packages.
Anyway, all will become clear when you post a patch.
- mingw32-macros.mingw32 for a compact cxxflags, is there any proposed
flags for c++ code?
No not really ... we tend to use the C flags for this too.
i've google around a bit about the sjlj <-> dwarf2 stuff and for me it seems in the current mingw release it's already dwarf2 by default. so i always vote for use the upstream mingw's default. the main problem here is that we've to decided which version to use since if we wanna switch we've to recompile _everything_ as different packages won't be compatible with eachother.
any comments?
Rebuilding all the packages is hugely time-consuming, so we need to be sure we understand what we're doing before this.
Rich.