[opensuse-factory] automake 1.12
Hi, To check what the automake 1.12 update would break, I gave it a run in openSUSE:Factory:Staging and this is the list of build failures in Staging that is not happening in openSUSE:Factory. There can be various reasons for the difference between the projects, but automake is the most likely. Unless someone prepares fixes for those, I'm declining the update for 12.2 Greetings, Stephan a2ps accountsservice agg apcupsd bcel byzanz canna castor cinnamon cmpi-bindings colord colord-gtk enscript evolution-tray findutils gcc33 GeoIP giggle glucat gnome-phone-manager gnome-session gnome-shell gnuplot gnutls grilo grilo-plugins gtk2 gupnp-ui heroes-tron jakarta-commons-dbcp jedit kakasi kernel-ec2 libcaca libfm libHBAAPI2 libhbalinux2 libqdialogsolver1 libqt4-devel-doc libreoffice-hyphen libreoffice-thesaurus libsyncml0 libxspf libzypp libzypp-testsuite-tools lightdm loki_setup lxappearance-obconf lxtask man minicom mutt myspell-dictionaries nautilus-image-converter netcf notify-osd open-fcoe patterns-openSUSE pcmanfm perl-Perl-PrereqScanner pidgin-otr pysol python3-base python-egenix-mx-base python-Sphinx recode sap-locale scim seed seed2 smartmontools splashy spyder systemtap-docs texinfo thttpd xemacs-packages yast2-core yast2-gtk yast2-ncurses-pkg yast2-pkg-bindings zypper -- If you lose a son you can always get another, but there's only one Maltese Falcon. -- Sidney Greenstreet, "The Maltese Falcon" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/29/2012 11:34 AM, Stephan Kulow wrote:
Hi,
To check what the automake 1.12 update would break, I gave it a run in openSUSE:Factory:Staging and this is the list of build failures in Staging that is not happening in openSUSE:Factory.
There can be various reasons for the difference between the projects, but automake is the most likely. Unless someone prepares fixes for those, I'm declining the update for 12.2
With the new automake, pkglib variable is now a reserved keyword. Here is how you fix it. Locate the code using pkglib variable: pkglib_DATA = pkgIndex.tcl Replace it with a workaround datalibdir=$(pkglibdir) datalib_DATA = pkgIndex.tcl Hope that helps. - -- Ismail Dönmez - openSUSE Booster SUSE LINUX Products GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPxJmGAAoJEJrs5hT7LFEcRI8H/1t000jNSdyWgLhva9NIy/eg /JE3jg2vsGtjoExs7fpP0zz0kNhNknHn+GwtyFyoNkKwyOYtaUBVJoxDl2k/9gFi AYFnjGrAueoe/vebmqiS9UBP4xf9Z23/RnlablWtAEoe+ZGoQO/Gh3zrTFp4toN6 YzyIL/9myyRqRe8xrrGpCGMG3sPPVzcjjlYvxueySZ2mh44fbOt+eJJ1QUSkzgs9 NMJ+WIpdkGkg1G8LxFCvDGRTysWbgDtk/Ex5aDNUQHWJOxDArLW+fXtLhqs+IwTy 9aaMpIH6qJEVCCf+DfsOBc0iYfbMvU02rUFZOHdj1zSfLO4d0VZsSmLCZiS9btI= =OeBo -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2012-05-29 11:40, Ismail Dönmez wrote:
To check what the automake 1.12 update would break, I gave it a run in openSUSE:Factory:Staging and this is the list of build failures in Staging that is not happening in openSUSE:Factory.
There can be various reasons for the difference between the projects, but automake is the most likely. Unless someone prepares fixes for those, I'm declining the update for 12.2
With the new automake, pkglib variable is now a reserved keyword. Here is how you fix it.
Locate the code using pkglib variable:
pkglib_DATA = pkgIndex.tcl
Replace it with a workaround
datalibdir=$(pkglibdir) datalib_DATA = pkgIndex.tcl
It's not really a fix, but more of a hack. Data should ideally live in - you guessed it - pkgdatadir. (pkgdata_DATA = pkgIndex.tcl) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/29/2012 11:45 AM, Jan Engelhardt wrote:
On Tuesday 2012-05-29 11:40, Ismail Dönmez wrote:
To check what the automake 1.12 update would break, I gave it a run in openSUSE:Factory:Staging and this is the list of build failures in Staging that is not happening in openSUSE:Factory.
There can be various reasons for the difference between the projects, but automake is the most likely. Unless someone prepares fixes for those, I'm declining the update for 12.2
With the new automake, pkglib variable is now a reserved keyword. Here is how you fix it.
Locate the code using pkglib variable:
pkglib_DATA = pkgIndex.tcl
Replace it with a workaround
datalibdir=$(pkglibdir) datalib_DATA = pkgIndex.tcl
It's not really a fix, but more of a hack. Data should ideally live in - you guessed it - pkgdatadir. (pkgdata_DATA = pkgIndex.tcl)
That would change the intended behaviour and would need fixes in other parts of the program too. Also this was just an example ;) Regards. - -- Ismail Dönmez - openSUSE Booster SUSE LINUX Products GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPxJ01AAoJEJrs5hT7LFEcRoMH/iTVt/8gJCOLlCtORYnfdYlE lDIWqmQoEl0qCaNs4TD22YzjM6FErPtHBqXIz8OzdqDYd/Wp2XvrmHZpdE10SX7T zvWzCtHTumeye1Co5VmauarBmBzCT7TajCiv71WAerBO6yS5bnL8SkHyocfJ/ZlT DYyrVleNie2nWk56mb8Lc2jDKTbk6ZclBbPPiexhDHec7xilg8XcnZLilk39a/EL yHbQ114rJzC0Hik66VV9qOxSZafw7pS5JM7FDofURSWzl4zVWsq1GNi7SimcKeHJ 3NVBAi5nvMXZxzTajPuugKlsdFg6jskqs7CDU5t8XIhYGYUfrBM6MHSDMjMRgYE= =uGKf -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 29 May 2012, Ismail Dönmez wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/29/2012 11:34 AM, Stephan Kulow wrote:
Hi,
To check what the automake 1.12 update would break, I gave it a run in openSUSE:Factory:Staging and this is the list of build failures in Staging that is not happening in openSUSE:Factory.
There can be various reasons for the difference between the projects, but automake is the most likely. Unless someone prepares fixes for those, I'm declining the update for 12.2
With the new automake, pkglib variable is now a reserved keyword. Here is how you fix it.
Locate the code using pkglib variable:
pkglib_DATA = pkgIndex.tcl
Replace it with a workaround
datalibdir=$(pkglibdir) datalib_DATA = pkgIndex.tcl
Hope that helps.
The "fix" is of course to stop doing autoreconf in spec files. Upstream
decided on the automake/autoconf version it uses (well, at least if they
are shipping autogenerated files, which they should).
So first try that (check that SUSE local patches do properly edit both
source and generated files).
Richard.
--
Richard Guenther
On Tuesday 2012-05-29 15:33, Richard Guenther wrote:
To check what the automake 1.12 update would break, I gave it a run in openSUSE:Factory:Staging and this is the list of build failures in Staging that is not happening in openSUSE:Factory. With the new automake, pkglib variable is now a reserved keyword. Here is how you fix it.[...]
The "fix" is of course to stop doing autoreconf in spec files. Upstream decided on the automake/autoconf version it uses (well, at least if they are shipping autogenerated files, which they should). So first try that (check that SUSE local patches do properly edit both source and generated files).
I find patches touching autogenerated files unwieldy to maintain. Running autoreconf is, in many cases, not a problem, and upstream developers should be asked to try tuning their software to make it work with newer autotools suites, just like compiling with libfoo-devel-1.24 when the actual requirement that has been specified in the INSTALL/README reads "libfoo >= 1.23". -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 29 May 2012, Jan Engelhardt wrote:
On Tuesday 2012-05-29 15:33, Richard Guenther wrote:
To check what the automake 1.12 update would break, I gave it a run in openSUSE:Factory:Staging and this is the list of build failures in Staging that is not happening in openSUSE:Factory. With the new automake, pkglib variable is now a reserved keyword. Here is how you fix it.[...]
The "fix" is of course to stop doing autoreconf in spec files. Upstream decided on the automake/autoconf version it uses (well, at least if they are shipping autogenerated files, which they should). So first try that (check that SUSE local patches do properly edit both source and generated files).
I find patches touching autogenerated files unwieldy to maintain.
Why exactly?
Running autoreconf is, in many cases, not a problem, and upstream developers should be asked to try tuning their software to make it work with newer autotools suites, just like compiling with libfoo-devel-1.24 when the actual requirement that has been specified in the INSTALL/README reads "libfoo >= 1.23".
Well, "in many cases" - apart from those in the list that started
this thread.
autotools are not trying to maintain compatibility, so what works
with newer versions does not work with older versions. At least
you create issues with building a package for multiple distributions
if you use autoreconf. More so if you don't.
So, avoid it when possible.
Richard.
--
Richard Guenther
On Tuesday 2012-05-29 16:31, Richard Guenther wrote:
I find patches touching autogenerated files unwieldy to maintain.
Why exactly?
For example, there is a new warning in automake 1.12 that moans about AM_PROG_AR being absent when intending to create a .la archive. So, one has to add a *1-line* patch to the package iff it used AM_INIT_AUTOMAKE([-Werror]). The expanded form, as you suggest, of this change would be a 270+-line patch. Second case: adding foo=bar; AC_SUBST([foo]) to configure.ac. That's a 2-line patch. The more Makefiles a package has, the bigger your patch gets. And dare you made a typo.
Running autoreconf is, in many cases, not a problem, and upstream developers should be asked to try tuning their software to make it work with newer autotools suites, just like compiling with libfoo-devel-1.24 when the actual requirement that has been specified in the INSTALL/README reads "libfoo >= 1.23".
Well, "in many cases" - apart from those in the list that started this thread.
I've been through a few from the list, and they have been in the large part the AM_PROG_AR-type kind.
autotools are not trying to maintain compatibility,
They damn well do. You can still specify (IMHO way too many) old forms. Prime examples are AC_INIT([src/foo.c]) AM_INIT_AUTOMAKE([pkg], [version]) Just like with recent g++ releases, what was added in automake 1.12 was some form of stricter checking. It's just that it errors out on everybody who though using -Werror was fun.
At least you create issues with building a package for multiple distributions if you use autoreconf.
Clearly this is not the case if done right. Else I'd be having repeated bug reports about all the (upstream) projects of mine. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 29 May 2012, Jan Engelhardt wrote:
On Tuesday 2012-05-29 16:31, Richard Guenther wrote:
I find patches touching autogenerated files unwieldy to maintain.
Why exactly?
For example, there is a new warning in automake 1.12 that moans about AM_PROG_AR being absent when intending to create a .la archive. So, one has to add a *1-line* patch to the package iff it used AM_INIT_AUTOMAKE([-Werror]). The expanded form, as you suggest, of this change would be a 270+-line patch.
No. You don't need to patch anything here if you do not run autoreconf.
Second case: adding foo=bar; AC_SUBST([foo]) to configure.ac. That's a 2-line patch. The more Makefiles a package has, the bigger your patch gets. And dare you made a typo.
Sure. For plain above make foo=bar might also work though.
Running autoreconf is, in many cases, not a problem, and upstream developers should be asked to try tuning their software to make it work with newer autotools suites, just like compiling with libfoo-devel-1.24 when the actual requirement that has been specified in the INSTALL/README reads "libfoo >= 1.23".
Well, "in many cases" - apart from those in the list that started this thread.
I've been through a few from the list, and they have been in the large part the AM_PROG_AR-type kind.
But there is no reason to fix that if there was no reason to run autoreconf.
autotools are not trying to maintain compatibility,
They damn well do. You can still specify (IMHO way too many) old forms. Prime examples are
AC_INIT([src/foo.c]) AM_INIT_AUTOMAKE([pkg], [version])
Just like with recent g++ releases, what was added in automake 1.12 was some form of stricter checking. It's just that it errors out on everybody who though using -Werror was fun.
At least you create issues with building a package for multiple distributions if you use autoreconf.
Clearly this is not the case if done right. Else I'd be having repeated bug reports about all the (upstream) projects of mine.
Well, there are tons of cases where AM_* was renamed to AC_* but the latter is only available with newer autotools. So for SLE9 you won't get autoreconf to succeed (well, or succeed with warnings but generate broken scripts). Richard. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2012-05-29 16:53, Richard Guenther wrote:
On Tue, 29 May 2012, Jan Engelhardt wrote:
On Tuesday 2012-05-29 16:31, Richard Guenther wrote:
I find patches touching autogenerated files unwieldy to maintain.
Why exactly?
For example, there is a new warning in automake 1.12 that moans about AM_PROG_AR being absent when intending to create a .la archive. So, one has to add a *1-line* patch to the package iff it used AM_INIT_AUTOMAKE([-Werror]). The expanded form, as you suggest, of this change would be a 270+-line patch.
No. You don't need to patch anything here if you do not run autoreconf.
Indeed. But consider a2ps, which was also on the list. I am attempting to rebase the patches to a2ps-4.14. I have seen at least one patch now that touched Makefile.ins in ways where I have no clue what the F the original patch creator did - or whether the diff is in fact the result of rerunning autoreconf or so. In short: patches to Makefile.in are more often than not absolutely non-descriptive. All I can do about that is rip out hunks (avoiding the patch conflict) or in fact splice (resolve the conflict) them into 4.14, and neither choice gives me any confidence. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 29 May 2012, Jan Engelhardt wrote:
On Tuesday 2012-05-29 16:53, Richard Guenther wrote:
On Tue, 29 May 2012, Jan Engelhardt wrote:
On Tuesday 2012-05-29 16:31, Richard Guenther wrote:
I find patches touching autogenerated files unwieldy to maintain.
Why exactly?
For example, there is a new warning in automake 1.12 that moans about AM_PROG_AR being absent when intending to create a .la archive. So, one has to add a *1-line* patch to the package iff it used AM_INIT_AUTOMAKE([-Werror]). The expanded form, as you suggest, of this change would be a 270+-line patch.
No. You don't need to patch anything here if you do not run autoreconf.
Indeed. But consider a2ps, which was also on the list. I am attempting to rebase the patches to a2ps-4.14.
I have seen at least one patch now that touched Makefile.ins in ways where I have no clue what the F the original patch creator did - or whether the diff is in fact the result of rerunning autoreconf or so.
In short: patches to Makefile.in are more often than not absolutely non-descriptive. All I can do about that is rip out hunks (avoiding the patch conflict) or in fact splice (resolve the conflict) them into 4.14, and neither choice gives me any confidence.
Oh, sure - you definitely should patch _both_, Makefile.in _and_
Makefile.am. And re-generate Makefile.in (and create a patch for it)
with exactly the same autotools versions that the file was created with
(to avoid spuriously large diffs).
Richard.
--
Richard Guenther
On Wednesday 2012-05-30 11:09, Richard Guenther wrote:
Indeed. But consider a2ps, which was also on the list. I am attempting to rebase the patches to a2ps-4.14.
I have seen at least one patch now that touched Makefile.ins in ways where I have no clue what the F the original patch creator did - or whether the diff is in fact the result of rerunning autoreconf or so. [...]
Oh, sure - you definitely should patch _both_, Makefile.in _and_ Makefile.am. And re-generate Makefile.in (and create a patch for it) with exactly the same autotools versions that the file was created with (to avoid spuriously large diffs).
Good luck finding # Makefile.in generated automatically by automake 1.4a from Makefile.am in any recent openSUSE release :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 30 May 2012, Jan Engelhardt wrote:
On Wednesday 2012-05-30 11:09, Richard Guenther wrote:
Indeed. But consider a2ps, which was also on the list. I am attempting to rebase the patches to a2ps-4.14.
I have seen at least one patch now that touched Makefile.ins in ways where I have no clue what the F the original patch creator did - or whether the diff is in fact the result of rerunning autoreconf or so. [...]
Oh, sure - you definitely should patch _both_, Makefile.in _and_ Makefile.am. And re-generate Makefile.in (and create a patch for it) with exactly the same autotools versions that the file was created with (to avoid spuriously large diffs).
Good luck finding
# Makefile.in generated automatically by automake 1.4a from Makefile.am
in any recent openSUSE release :)
Ok, it's not in my list of local installs either.
ls /suse/rguenther/install/ autoconf-2.13 autoconf-2.64 automake-1.11.1 automake-1.9.6 autoconf-2.59 automake-1.11 automake-1.9.3 rzip-2.0
but it should be easy to download and install locally for the sake
of package maintainance. (You see I've done that for some versions ...)
Richard.
--
Richard Guenther
On 29/05/12 10:44, Jan Engelhardt wrote:
On Tuesday 2012-05-29 16:31, Richard Guenther wrote:
I find patches touching autogenerated files unwieldy to maintain.
Why exactly?
For example, there is a new warning in automake 1.12 that moans about AM_PROG_AR being absent when intending to create a .la archive.
Isnt this a bug in libtool ? if AM_PROG_AR is needed to create a ".la" archive then libtool should call it if defined or I am missing something ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 29.05.2012 15:33, Richard Guenther wrote:
On Tue, 29 May 2012, Ismail Dönmez wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/29/2012 11:34 AM, Stephan Kulow wrote:
Hi,
To check what the automake 1.12 update would break, I gave it a run in openSUSE:Factory:Staging and this is the list of build failures in Staging that is not happening in openSUSE:Factory.
There can be various reasons for the difference between the projects, but automake is the most likely. Unless someone prepares fixes for those, I'm declining the update for 12.2
With the new automake, pkglib variable is now a reserved keyword. Here is how you fix it.
Locate the code using pkglib variable:
pkglib_DATA = pkgIndex.tcl
Replace it with a workaround
datalibdir=$(pkglibdir) datalib_DATA = pkgIndex.tcl
Hope that helps.
The "fix" is of course to stop doing autoreconf in spec files. Upstream decided on the automake/autoconf version it uses (well, at least if they are shipping autogenerated files, which they should).
How else do you handle cases where you need to modify the build system (configure.ac, Makefile.am and friends)? Most of the time it works, but I find this is a fundamental flaw in autotools. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 29 May 2012, Guido Berhoerster wrote:
On 29.05.2012 15:33, Richard Guenther wrote:
The "fix" is of course to stop doing autoreconf in spec files. Upstream decided on the automake/autoconf version it uses (well, at least if they are shipping autogenerated files, which they should).
How else do you handle cases where you need to modify the build system (configure.ac, Makefile.am and friends)? Most of the time it works, but I find this is a fundamental flaw in autotools.
Either run autoreconf locally and include the autogenerated files in the patch too. Or at least don't use the full autoreconf but only the commands which are actually needed. BTW usually make would do this for you. For example instead of the current tar package does now: sed -i -e 's@need runtime check@yes@g' m4/*.m4 autoreconf -fiv %configure make which breaks the build on almost all repos... we could do this: %configure sed -i -e 's@need runtime check@yes@g' m4/*.m4 make Now make will invoke the needed aclocal, autoconf and automake and configure again. But in this example probably sed -i -e 's@need runtime check@yes@g' configure would be enough to avoid the automake dep completely. Generally I would say that we have too much packages where autoreconf is called for no good reason. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 30.05.2012 13:38, Ruediger Meier wrote:
which breaks the build on almost all repos...
we could do this: %configure sed -i -e 's@need runtime check@yes@g' m4/*.m4 make Now make will invoke the needed aclocal, autoconf and automake and configure again.
"the needed" is the key phrase here. Which means it will call automake-1.9 and will ignore it if not present. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 30 May 2012, Stephan Kulow wrote:
On 30.05.2012 13:38, Ruediger Meier wrote:
which breaks the build on almost all repos...
we could do this: %configure sed -i -e 's@need runtime check@yes@g' m4/*.m4 make Now make will invoke the needed aclocal, autoconf and automake and configure again.
"the needed" is the key phrase here. Which means it will call automake-1.9 and will ignore it if not present.
Yes, relying on make calling autoconf & friends does not sound reliable.
Btw, for most cases (and surely the above) injecting some autoconf
cache variable works
ac_cv_INSERT_FLAG_NAME_HERE=yes \
%configure
so you can inject the outcome of certain tests.
Which means, not only try to avoid calling autoreconf in spec files,
but try to avoid messing with the configury and make system. If possible,
of course.
Richard.
--
Richard Guenther
On Wednesday 30 May 2012, Richard Guenther wrote:
On Wed, 30 May 2012, Stephan Kulow wrote:
On 30.05.2012 13:38, Ruediger Meier wrote:
which breaks the build on almost all repos...
we could do this: %configure sed -i -e 's@need runtime check@yes@g' m4/*.m4 make Now make will invoke the needed aclocal, autoconf and automake and configure again.
"the needed" is the key phrase here. Which means it will call automake-1.9 and will ignore it if not present.
Yes, relying on make calling autoconf & friends does not sound reliable.
At least this is nice way to see what commands are needed to run them locally to create a minimalistic patch which does not need autotools deps within the spec file. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2012-05-29 11:34, Stephan Kulow wrote:
To check what the automake 1.12 update would break, I gave it a run in openSUSE:Factory:Staging and this is the list of build failures in Staging that is not happening in openSUSE:Factory.
libcaca: 122719 State:accepted libfm: 122720 State:new libHBAAPI2: 122722 State:new libhbalinux2: 122724 State:new libqdialogsolver1: gcc47, not automake problem AFAICS libsyncml0: it succeeded in o:F:Staging, so what? libxspf: 122727 State:accepted In fm and HBA, the culprit is rather -Werror, which now fires beacuse am 1.12 gives new warnings for outdated constructs. So far it goes... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2012-05-29 11:34, Stephan Kulow wrote:
agg
Fix submitted.
apcupsd
Fix submitted.
bcel
The develprj already compiles. Please source from there. (Also check other packages whether the DP already works, and just has not been submitted yet towards factory.)
byzanz
The error is to be sought in gnome-common, whose gnome-autogen.sh script only checks for the presence of certain automake versions. I find that dull because it means you have to edit gnome-common for every new automake/autoconf/etc. release. The GNOME people should relax this and attempt to use plain "automake" (even if it's "too new" for their taste).
canna
Did it not occur to people that cp /usr/share/automake-1.11/config.* ... eventually ceases to work? Thankfully there are only 5 such packages in factory. Fix for canna submitted.
castor
Already succeeded in staging
cinnamon
gnome-common idiocy
cmpi-bindings
succeeded in staging already
colord
gnome-common
colord-gtk
gnome-common
enscript
fix submitted to develprj
evolution-tray
gnome-common. Again. See, this is why it's important to fix gnome-autogen.sh ... :/
findutils
somebody already has a fix in the develprj
GeoIP
Fix is accepted into develprj.
giggle -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (7)
-
Cristian Rodríguez -
Guido Berhoerster -
Ismail Dönmez -
Jan Engelhardt -
Richard Guenther -
Ruediger Meier -
Stephan Kulow