Discussion:
Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
(too old to reply)
Jakub Jelinek
2011-12-31 11:56:49 UTC
Permalink
Hi!

As part of preparations to switch GCC in F17 to GCC 4.7.0, I've performed
a test mass rebuild of rawhide (December 23th package list) using
gcc-4.7.0-0.1.fc17 on x86_64, and for those packages that failed also
rebuilt the same package with gcc-4.6.2-1.fc16 to quickly remove from the
list packages that fail for non-gcc related reasons.
Out of the 11270 packages I've built, 10056 packages built fine with
gcc-4.7.0-0.1.fc17 and 845 packages failed to build also with
gcc-4.6.2-1.fc16, so I'm ignoring those from any analysis.
I've analyzed some of the remaining failures and tried to categorize it
a little bit. There were 3 internal compiler errors seen during the
whole mass rebuild, http://gcc.gnu.org/PR5169{2,4,5} are currently
filed and slightly analyzed, but not fixed yet.

CCing Benjamin if he'd be interested to write
http://gcc.gnu.org/gcc-4.7/porting_to.html again this time.

The common reasons for build failures were (I'm attaching srpm lists for
these categories):

http://gcc.gnu.org/PR49745 119 failures
<iostream>, <string> and other STL headers that previously
included <unistd.h> as an implementation detail (to get some
feature macros for gthr*.h purposes) no longer do so (it was
a C++ standard violation), to fix this up just add
#include <unistd.h> early in the sources (or headers) that need it.

http://gcc.gnu.org/PR24163 60 failures
http://gcc.gnu.org/PR29131 28 failures
C++ lookup fixes, the C++ FE no longer performs an extra unqualified
lookup that it (incorrectly) performed in the past. In some cases the
diagnostics includes hints how to fix the bugs, for PR24163 the
diagnostics looks like:
error: 'something' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
note: declarations in dependent base 'someclass<somearg>' are not found by unqualified lookup
note: use 'this->something' instead
and for PR29131 diagnostics looks like:
error: 'something' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
note: 'template<class T1, class T2> sometype something(T1&, const T2&)' declared here, later in the translation unit

checking for stdbool.h that conforms to C99... no 2 failures
but affects other 150+ packages
apparently autoconf 2.60 through autoconf 2.67 contains an invalid
check in its stdbool.h checking macro:
# if defined __xlc__ || defined __GNUC__
/* Catch a bug in IBM AIX xlc compiler version 6.0.0.0
reported by James Lemley on 2005-10-05; see
http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html
This test is not quite right, since xlc is allowed to
reject this program, as the initializer for xlcbug is
not one of the forms that C requires support for.
However, doing the test right would require a runtime
test, and that would make cross-compilation harder.
Let us hope that IBM fixes the xlc bug, and also adds
support for this kind of constant expression. In the
meantime, this test will reject xlc, which is OK, since
our stdbool.h substitute should suffice. We also test
this with GCC, where it should work, to detect more
quickly whether someone messes up the test in the
future. */
char digs[] = "0123456789";
int xlcbug = 1 / (&(digs + 5)[-2 + (bool) 1] == &digs[4] ? 1 : -1);
# endif
As written, the test is not quite right and a conforming C compiler
is not required to accept it and starting with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172958
GCC rejects it (and similarly from what I understood from autoconf
2.68 notes recent xlc rejects it as well). autoconf 2.68 dropped
this incorrect check, but apparently many packages include their
own configure scripts without regenerating them. Wonder what is the
best thing to do here, ask package maintainers to grep for this
int xlcbug = ...; in their packages and sedding that to
int xlcbug = 0;, or dropping that || defined __GNUC__ above the
invalid test, or asking where possible to regenerate configure with
autoconf 2.68, perhaps some rpm-build script to do the sedding?
Most of the 150+ packages just refused to use the system <stdbool.h>
because of this and did something else (either provided their own
stdbool.h alternative, falled back to using int instead of bool,
...), the 2 failures were just cases where this was a fatal failure.

https://svn.boost.org/trac/boost/ticket/6165 26 failures
Apparently boost uses some libstdc++-v3 internal macros to determine
if gcc has been configured with or without thread support, in GCC 4.7
these internal macros changed and boost thinks GCC 4.7.0 no longer
supports threads (e.g. in libstdc++ headers). The fix here will be
just to fix up boost package we include.

gcc driver became more picky about
bogus options during linking 14 failures
GCC 4.6 and earlier apparently didn't complain about completely
invalid options on gcc/g++/gfortran etc. command lines, if
nothing was compiled, but only linking was performed.
E.g. gcc -Wl -o foo foo.o -mflat_namespace
would work just fine, even when -Wl needs to have some option
to pass to the linker after it and -mflat_namespace isn't supported
at all. Garbage options just need to be removed from the command
line or replaced by something that is actually supported.

http://gcc.gnu.org/PR2288 8 failures
For C++, GCC 4.6 and earlier incorrectly put the two
declarations in different scopes in cases like:
for (int i = 0; i < 10; i++)
{
int i = 2;
}
While that is valid C99 (where there is a separate scope
with the for declared vars and { int i = 2; } is another scope
inside it), in C++ this is invalid, the int i = 0; declaration
goes into the same scope as the body of the for cycle (similarly
for if/switch). To fix this, either rename one of the decls,
or if you really meant to have the same name and want to have
them in different scopes, add another pair of {}s around the body.
With
for (int i = 0; i < 10; i++)
{{
int i = 2;
}}
the inner {} is already a nested scope.

user defined literal support 3 failures
When compiling C++ with -std={c++11,c++0x,gnu++11,gnu++0x} GCC 4.7.0
unlike older versions supports user defined literals, which are
incompatible with some valid ISO C++03 code.
In particular, whitespace is now needed after a string literal
before something that could be a valid user defined literal.
Say const char *p = "foobar"__TIME__; is valid C++03, the __TIME__
macro expands to some string literal and is concatenated with the
other one. In C++11 __TIME__ isn't expanded, instead operator ""
__TIME__ is being looked up. This applies to any string literal
followed without whitespace by some macro. Just add some whitespace
between the string literal and the macro name.

-Werror 12 failures
As usually, packages compiled with -Werror sometimes fail because
newer GCC versions emit slightly different warnings (could be
correct warnings, newly introduced warnings, could be even false
positives, but with -Werror you need to be prepared to workaround
them).

libgcj 6 failures
gcc-4.7.0-0.1.fc17 contained a packaging bug for libgcj, the
libgcj.so symlink incorrectly pointed to libgcj.so.12 instead
of libgcj.so.13. Will fix this for -0.2.fc17, to this category
I've also included package failures where non-indirect-dispatch
gcj built packages failed to build due to their dependencies
not finding libgcj.so.12 dependency. Those will just need to
be rebuilt.

unanalyzed 91 failures
Ran out of time, haven't analyzed the remaining ones (other
category), once gcc-4.7.0-0.*.fc17 hits the buildroots,
please try to analyze these. Could be gcc bugs, but could
very well be package bugs. E.g. in glibc (which built fine,
just failed a couple of tests that previously succeeded),
I've discovered it was a glibc bug:
http://sources.redhat.com/ml/libc-alpha/2011-12/msg00091.html

Jakub
-------------- next part --------------
alure-1.2-1.fc17.src.rpm
apt-0.5.15lorg3.95-2.git522.1.fc17.src.rpm
aria2-1.12.1-1.fc17.src.rpm
arpage-0.3.3-7.fc17.src.rpm
bangarang-2.0.1-1.fc16.src.rpm
barry-0.17.1-5.fc17.src.rpm
bes-3.9.0-1.fc15.src.rpm
blahtexml-0.8-3.fc16.src.rpm
calf-0.0.18.6-4.fc17.src.rpm
clamav-0.97.3-1700.fc17.src.rpm
ClanLib-2.3.4-2.fc17.src.rpm
clucene-2.3.3.4-3.fc16.src.rpm
cmake-2.8.7-0.1.rc1.fc17.src.rpm
code-editor-2.3.1-11.fc17.src.rpm
conexus-0.9.1-3.fc14.1.src.rpm
coot-0.6.2-10.20110715svn3566.fc17.src.rpm
cppcheck-1.52-1.fc17.src.rpm
cryptkeeper-0.9.5-3.fc17.src.rpm
CTL-1.4.1-11.fc15.src.rpm
cyphesis-0.5.26-2.fc17.src.rpm
dbus-cxx-0.7.0-2.fc14.1.src.rpm
fastx_toolkit-0.0.13-4.fc16.src.rpm
fawkes-0.4.2-8.fc17.src.rpm
freenx-client-0.9-11.fc15.src.rpm
fusecompress_offline1-1.99.19-7.fc15.src.rpm
fwbuilder-4.1.2-1.fc15.src.rpm
gdisk-0.8.1-2.fc17.src.rpm
gearbox-9.11-8.fc15.src.rpm
gearmand-0.23-2.fc17.src.rpm
goldendict-1.0.1-4.fc16.src.rpm
gst123-0.2.1-2.fc17.src.rpm
guimup-0.2.1-4.fc17.src.rpm
gwenhywfar-4.3.0-1.fc17.src.rpm
hercstudio-1.3.0-1.fc16.src.rpm
icc_examin-0.49-1.fc16.src.rpm
ice-3.4.2-5.fc17.src.rpm
incron-0.5.9-2.fc15.src.rpm
kaya-0.5.2-11.fc17.1.src.rpm
kdebase-workspace-4.7.95-1.fc17.src.rpm
kdegames-4.7.95-1.fc17.src.rpm
keepassx-0.4.3-2.fc15.src.rpm
kid3-2.0.1-1.fc16.src.rpm
komparator-0.9-5.fc15.src.rpm
koverartist-0.5-14.fc15.src.rpm
libconcord-0.23-7.fc16.src.rpm
libdigidocpp-0.3.0-10.fc17.src.rpm
libffado-2.1.0-0.4.20111030.svn2000.fc17.src.rpm
libfreebob-1.0.11-8.fc15.src.rpm
libfwbuilder-4.1.2-1.fc15.src.rpm
libkml-0.6.1-8.fc15.src.rpm
libkni3-3.9.2-13.fc15.src.rpm
libmnetutil-0.8.0-0.3.20100629svn3775.fc15.src.rpm
libmsn-4.2.1-1.fc17.src.rpm
libofa-0.9.3-18.fc17.src.rpm
libofx-0.9.4-1.fc16.src.rpm
libvoikko-3.3.1-0.3.rc1.fc17.src.rpm
libvpd-2.1.1-2.fc15.src.rpm
libwvstreams-4.6.1-3.fc15.src.rpm
lmms-0.4.11-1.fc16.src.rpm
matahari-0.6.0-1.fc17.src.rpm
minetest-0.3.1-6.fc17.src.rpm
minicomputer-1.41-5.fc16.src.rpm
minitunes-1.0-1.fc17.src.rpm
mozc-1.3.930.102-1.fc17.src.rpm
ncmpcpp-0.5.8-1.fc17.src.rpm
newsbeuter-2.4-1.fc16.src.rpm
numptyphysics-0.3-0.6.20080925svn.fc15.src.rpm
oggvideotools-0.8-4.fc17.src.rpm
ois-1.2.0-3.fc15.src.rpm
openscada-0.7.1-6.fc17.src.rpm
ovaldi-5.9.1-1.fc16.src.rpm
podofo-0.9.1-2.fc17.src.rpm
posterazor-1.5-8.fc16.src.rpm
powertop-1.98-2.fc17.src.rpm
psi-0.14-7.fc17.src.rpm
pxe-kexec-0.2.3-3.fc15.src.rpm
qpid-cpp-0.12-6.fc17.2.src.rpm
qt-creator-2.4.0-0.0.rc.fc17.src.rpm
qterm-0.5.12-1.fc16.src.rpm
qt-mobility-1.2.0-6.20110922.fc17.src.rpm
qtsingleapplication-2.6.1-5.fc15.src.rpm
qutim-0.2.0-9.fc15.src.rpm
rafkill-1.2.3-7.fc16.src.rpm
rekall-2.4.6-17.fc16.src.rpm
rinputd-1.0.4-1.fc16.src.rpm
scim-bridge-0.4.16-7.fc17.src.rpm
scim-fcitx-3.1.1-12.fc15.src.rpm
scim-hangul-0.3.2-9.fc17.src.rpm
scorched3d-43.2a-5.fc17.src.rpm
seamonkey-2.5-2.fc17.src.rpm
sems-1.4.2-2.fc17.src.rpm
smartcardpp-0.3.0-1.fc17.src.rpm
sonic-visualiser-1.8-3.fc17.src.rpm
spectrum-1.4.8-4.fc17.src.rpm
strigi-0.7.6-4.fc17.src.rpm
sunpinyin-2.0.3-2.fc17.src.rpm
svxlink-11.11.1-4.fc17.src.rpm
synaptic-0.57.2-27.fc17.src.rpm
systemtap-1.6-1.fc16.src.rpm
task-1.9.4-1.fc16.src.rpm
telepathy-qt4-0.8.0-2.fc17.src.rpm
tellico-2.3.4-1.fc17.src.rpm
tesseract-3.00-2.fc15.src.rpm
thunderbird-9.0-4.fc17.src.rpm
thunderbird-lightning-1.1-0.1.rc1.fc17.src.rpm
ultimatestunts-0.7.6-1.fc16.src.rpm
uncrustify-0.58-1.fc16.src.rpm
urg-0.8.11-2.fc16.src.rpm
valknut-0.4.9-4.fc15.src.rpm
vios-proxy-0.2-1.fc17.src.rpm
vym-2.0.4-1.fc17.src.rpm
webkitgtk3-1.7.2-1.fc17.src.rpm
wpa_supplicant-0.7.3-11.fc17.src.rpm
xdrawchem-1.9.9-15.fc15.src.rpm
xmoto-0.5.9-1.fc17.src.rpm
xsupplicant-2.2.0-3.fc15.src.rpm
xxdiff-3.2-14.fc15.src.rpm
zoneminder-1.24.4-3.fc17.src.rpm
zorba-2.1.0-1.fc17.src.rpm
-------------- next part --------------
4ti2-1.3.2-8.fc17.src.rpm
activemq-cpp-3.4.0-1.fc17.src.rpm
aplus-fsf-4.22.4-21.fc16.src.rpm
armacycles-ad-0.2.8.3.1-5.fc17.src.rpm
asc-2.4.0.0-3.fc17.src.rpm
bibletime-2.8.2-1.fc17.src.rpm
blobby-0.9c-1.fc17.src.rpm
btanks-0.9.8083-1.fc16.src.rpm
cantor-4.7.95-1.fc17.src.rpm
cryptopp-5.6.1-5.fc17.src.rpm
dcmtk-3.6.0-8.fc17.src.rpm
ember-0.6.2-2.fc17.src.rpm
ETL-0.04.13-2.fc15.src.rpm
fatrat-1.2.0-0.1.beta1.fc17.src.rpm
festival-1.96-18.fc16.src.rpm
freefem++-3.12-1.fc17.src.rpm
frepple-0.9.0-1.fc17.src.rpm
ginac-1.5.8-3.fc16.src.rpm
givaro-3.5.0-1.fc17.src.rpm
gsmartcontrol-0.8.6-3.fc17.src.rpm
gtkmathview-0.8.0-6.fc13.src.rpm
hugin-2011.2.0-4.fc17.src.rpm
k3d-0.8.0.2-5.fc17.src.rpm
kdemultimedia-4.7.95-1.fc17.src.rpm
kdepim3-3.5.10-5.fc15.src.rpm
kdevelop-php-1.2.3-1.fc16.src.rpm
klatexformula-3.2.3-3.fc16.src.rpm
kvirc-4.0.4-2.fc16.src.rpm
lordsawar-0.2.0-4.fc17.src.rpm
mediatomb-0.12.1-14.fc17.src.rpm
mimetic-0.9.6-2.fc15.src.rpm
mldonkey-3.0.3-3.fc17.src.rpm
mm3d-1.3.8a-2.fc15.src.rpm
mrpt-0.9.5-0.2.20110917svn2662.fc17.src.rpm
netpanzer-0.8.3.svn612010-4.fc16.src.rpm
nurbs++-3.0.11-9.fc16.src.rpm
octave-symbolic-1.1.0-1.fc17.src.rpm
piklab-0.15.10-3.fc15.src.rpm
pycryptopp-0.5.29-1.fc15.src.rpm
python-polybori-0.7.2-4.fc17.src.rpm
qca2-2.0.3-2.fc15.src.rpm
ragel-6.6-3.fc15.src.rpm
sblim-wbemcli-1.6.2-1.fc16.src.rpm
schroot-1.4.23-2.fc17.src.rpm
sphinx-0.9.9-6.fc16.src.rpm
spicebird-0.7.1-1.fc11.src.rpm
sword-1.6.2-5.fc17.src.rpm
synfigstudio-0.62.02-1.fc15.src.rpm
tripwire-2.4.1.2-11.fc12.src.rpm
tuxcmd-0.6.70-3.fc17.src.rpm
vdr-1.7.22-1.fc17.src.rpm
vdr-epgsearch-1.0.0-5.fc17.src.rpm
vdr-streamdev-0.5.1-6.fc17.src.rpm
vdr-sudoku-0.3.5-5.fc17.src.rpm
vdr-ttxtsubs-0.2.4-2.fc17.src.rpm
vdr-wapd-0.9-12.patch1.fc17.src.rpm
vfrnav-0.6-3.fc17.src.rpm
vigra-1.8.0-2.fc17.src.rpm
xqilla-2.2.4-2.fc17.src.rpm
xsd-3.3.0-8.fc17.src.rpm
-------------- next part --------------
3Depict-0.0.9-1.fc17.src.rpm
boolstuff-0.1.13-2.fc15.src.rpm
bowtie-0.12.7-2.fc16.src.rpm
codeblocks-10.05-6.fc17.src.rpm
Coin2-2.5.0-11.fc17.src.rpm
cppad-20110101.5-1.fc17.src.rpm
glest-3.2.2-8.fc16.src.rpm
gnome-commander-1.2.8.15-1.fc17.src.rpm
gource-0.37-1.fc17.src.rpm
kdelibs-4.7.95-1.fc17.src.rpm
kicad-2011.07.12-2.rev3047.fc16.src.rpm
krusader-2.4.0-0.2.beta1.fc17.src.rpm
lyx-2.0.2-1.fc17.src.rpm
mercator-0.3.0-2.fc16.src.rpm
mingw32-nsis-2.46-3.fc17.src.rpm
nted-1.10.18-3.fc17.src.rpm
octave-signal-1.1.1-1.fc17.src.rpm
openlierox-0.57-0.16.beta8.fc15.src.rpm
openttd-1.1.3-2.fc17.src.rpm
protobuf-2.4.1-2.fc17.src.rpm
raul-0.8.0-2.fc15.src.rpm
rawtherapee-4.0.5-2.fc17.src.rpm
rcssserver3d-0.6.5-5.fc17.src.rpm
sear-0.6.4-0.2.g0b70ddb.fc17.src.rpm
squirrel-2.2.4-2.fc15.src.rpm
stp-0.1-7.20111130svn.fc17.src.rpm
vegastrike-0.5.1-0.4.beta1.2.fc17.src.rpm
wfmath-0.3.11-2.fc16.src.rpm
-------------- next part --------------
gnuplot-4.4.4-1.fc17.src.rpm
strace-4.6-1.fc16.src.rpm
-------------- next part --------------
aqsis-1.6.0-13.fc17.src.rpm
boost141-1.41.0-2.fc17.src.rpm
boost-1.48.0-2.fc17.src.rpm
cegui-0.7.5-10.fc17.src.rpm
esteid-browser-plugin-1.3.2-2.fc17.src.rpm
Field3D-1.2.1-1.fc17.src.rpm
flush-0.9.10-5.fc17.src.rpm
glob2-0.9.4.4-9.fc17.src.rpm
gnash-0.8.9-7.fc17.src.rpm
gnuradio-3.5.0-2.fc17.src.rpm
LuxRender-0.8.0-9.fc17.src.rpm
meshmagick-0.6.0-9.svn2898.fc16.src.rpm
mygui-3.0.1-10.fc17.src.rpm
ogre-1.7.3-3.fc17.src.rpm
ogre-pagedgeometry-1.1.0-5.fc16.src.rpm
ompl-0.9.5-2.fc17.src.rpm
pdns-3.0-8.fc17.src.rpm
pion-net-4.0.7-4.fc17.src.rpm
player-3.0.2-15.fc17.src.rpm
pokerth-0.8.3-10.fc17.src.rpm
python-visual-5.72-2.fc17.src.rpm
qbittorrent-2.9.2-1.fc17.src.rpm
simspark-0.2.2-5.fc17.src.rpm
springlobby-0.139-1.fc17.src.rpm
tncfhh-0.8.3-4.fc17.src.rpm
uhd-3.3.1-1.fc17.src.rpm
-------------- next part --------------
fife-0.3.2-9.r2.fc17.src.rpm
grub2-1.99-14.fc17.src.rpm
jaffl-0.5.9-1.fc16.src.rpm
jffi-1.0.10-1.fc17.src.rpm
jnr-ffi-0.5.10-3.fc17.src.rpm
medusa-2.0-1.fc16.src.rpm
nekovm-1.8.1-5.fc17.src.rpm
openbabel-2.3.1-1.fc17.src.rpm
pianobooster-0.6.4b-3.fc15.src.rpm
qtwebkit-2.2.1-2.fc17.src.rpm
rubygem-ffi-1.0.9-2.fc16.src.rpm
skychart-3.2-5.fc16.src.rpm
spor-1.0-4.fc15.src.rpm
tcltls-1.6-7.fc15.src.rpm
-------------- next part --------------
gfan-0.5-1.fc17.2.src.rpm
inkscape-0.48.2-1.fc17.src.rpm
kaffeine-1.2.2-1.fc16.src.rpm
krecipes-1.0-0.2.beta2.fc15.src.rpm
muse-2.0-0.5.rc1.fc17.src.rpm
qalculate-kde-0.9.7-3.fc15.src.rpm
rosegarden4-11.11.11-1.fc17.src.rpm
xbase-3.1.2-2.fc15.src.rpm
-------------- next part --------------
CriticalMass-1.5-1.fc17.src.rpm
filezilla-3.5.2-1.fc17.1.src.rpm
pingus-0.7.4-4.fc17.src.rpm
-------------- next part --------------
binutils-2.22-1.fc17.src.rpm
elfutils-0.152-1.fc16.src.rpm
isomd5sum-1.0.7-1.fc16.src.rpm
java-1.6.0-openjdk-1.6.0.0-61.1.10.4.fc17.src.rpm
java-1.7.0-openjdk-1.7.0.1-2.0.3.fc17.src.rpm
krb5-1.10-0.fc17.alpha2.1.src.rpm
libtpms-0.5.1-12.src.rpm
linphone-3.4.3-1.fc17.src.rpm
mdadm-3.2.2-15.fc17.src.rpm
openswan-2.6.36-1.fc17.2.src.rpm
squid-3.2.0.14-2.fc17.src.rpm
v8-3.3.10-4.fc17.src.rpm
-------------- next part --------------
fmt-ptrn-1.3.21-2.fc15.src.rpm
libgconf-java-2.12.6-5.fc17.src.rpm
libglade-java-2.12.8-16.fc17.src.rpm
libvte-java-0.12.3-5.fc17.src.rpm
pdftk-1.44-5.fc16.src.rpm
wfut-1.1.0-9.fc15.src.rpm
-------------- next part --------------
adanaxisgpl-1.2.5-6.fc15.src.rpm
alliance-5.0-32.20090901snap.fc15.src.rpm
anthy-9100h-16.fc15.src.rpm
audacious-plugins-3.1.1-1.fc17.src.rpm
aunit-2010-3.fc16.src.rpm
avr-gcc-4.6.2-1.fc17.src.rpm
blender-2.61-1.fc17.src.rpm
bluez-4.96-3.fc17.src.rpm
cairo-java-1.0.8-4.fc15.src.rpm
ceph-0.37-2.fc17.src.rpm
clisp-2.49-4.fc16.src.rpm
curblaster-1.07-1.fc17.src.rpm
dopewars-1.5.12-10.1033svn.fc15.src.rpm
eigen2-2.0.15-2.fc15.src.rpm
faust-0.9.43-2.fc17.src.rpm
florist-2011-6.fc17.src.rpm
freeciv-2.3.0-1.fc17.src.rpm
frysk-0.4-32.fc17.src.rpm
gccxml-0.9.0-0.7.20111218.fc17.src.rpm
gforth-0.7.0-5.fc16.src.rpm
gigolo-0.4.1-3.fc17.src.rpm
git-1.7.8-1.fc17.src.rpm
glom-1.18.6-1.fc17.src.rpm
gnatcoll-2011-6.fc17.src.rpm
gnomeradio-1.8-16.fc17.src.rpm
gnome-schedule-2.1.5-1.fc17.src.rpm
gnome-subtitles-1.2-1.fc17.src.rpm
gnustep-back-0.20.0-3.fc17.src.rpm
gnustep-base-1.23.0-1.fc17.2.src.rpm
gnustep-examples-1.3.0-9.fc17.src.rpm
gnustep-gui-0.20.0-4.fc17.src.rpm
gorm-1.2.13-0.2.20110331.fc17.src.rpm
gprbuild-2010-9.fc16.src.rpm
grantlee-0.2.0-1.fc17.src.rpm
grass-6.4.1-5.fc17.src.rpm
hamster-applet-2.32.1-1.fc16.src.rpm
hotssh-0.2.7-3.fc15.src.rpm
icu-4.8.1-3.fc17.src.rpm
Inventor-2.1.5-40.fc15.src.rpm
iwhd-1.1-1.fc17.src.rpm
kdelibs3-3.5.10-32.fc17.src.rpm
kdenetwork-4.7.95-1.fc17.src.rpm
kdepim-4.7.95-1.fc17.src.rpm
kmplayer-0.11.2c-5.fc16.src.rpm
ldc-2-9.20111206gitfa5fb92.fc17.src.rpm
libjingle-0.6.0-2.fc17.src.rpm
librep-0.92.1-2.fc17.src.rpm
linbox-1.2.2-2.fc17.src.rpm
llvm-3.0-1.fc17.src.rpm
matreshka-0.1.1-9.fc17.src.rpm
memcached-1.4.10-1.fc17.src.rpm
meshlab-1.3.1-2.fc17.src.rpm
mingw32-gcc-4.6.1-3.fc17.2.src.rpm
mingw-gtk3-3.3.4-1.fc17.src.rpm
minion-0.10-7.fc17.src.rpm
mumble-1.2.3-5.fc17.src.rpm
mysql-5.5.18-1.fc17.src.rpm
octave-3.4.3-2.fc17.src.rpm
olpc-powerd-40-1.fc17.src.rpm
openCOLLADA-0-8.svn863.fc17.src.rpm
openscap-0.8.0-1.fc17.src.rpm
openslide-3.2.4-2.fc17.src.rpm
openvpn-auth-ldap-2.0.3-8.fc17.src.rpm
ORBit2-2.14.19-2.fc15.src.rpm
paraview-3.12.0-5.fc17.src.rpm
perl-Cache-Cache-1.06-7.fc16.src.rpm
perl-Qt-0.96.0-1.fc17.src.rpm
php-pear-Cache-Lite-1.7.12-1.fc17.src.rpm
plplot-5.9.9-1.fc17.src.rpm
pulseaudio-1.1-3.fc17.src.rpm
pure-0.48-1.fc17.src.rpm
python-gnutls-1.1.9-3.fc15.src.rpm
python-logilab-common-0.57.1-1.fc17.src.rpm
python-robofab-1.2.0-3.svn226.fc15.src.rpm
raidem-0.3.1-17.fc17.src.rpm
rb_libtorrent-0.15.8-2.fc17.src.rpm
rmol-0.25.3-2.fc17.src.rpm
root-5.30.04-1.fc17.src.rpm
rubygem-json-1.4.6-3.fc15.src.rpm
rubygem-rerun-0.6.2-1.fc17.src.rpm
scilab-5.3.3-5.fc17.src.rpm
sipwitch-1.1.3-1.fc17.src.rpm
soprano-2.7.4-1.fc17.src.rpm
sqlite-3.7.9-1.fc17.src.rpm
sudoku-savant-1.3-4.fc17.src.rpm
swift-1.0-6.fc17.src.rpm
tamil-typing-booster-0.0.1-5.fc17.src.rpm
travelccm-0.5.3-1.fc17.src.rpm
UnihanDb-5.1.0-7.fc15.3.src.rpm
webkitgtk-1.6.1-3.fc17.src.rpm
xemacs-21.5.31-3.fc17.src.rpm
Dennis Gilmore
2011-12-31 14:55:53 UTC
Permalink
if we plan to do a mass rebuild for gcc 4.7 we need to start it next week.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Jakub Jelinek <jakub at redhat.com> wrote:

Hi!

As part of preparations to switch GCC in F17 to GCC 4.7.0, I've performed
a test mass rebuild of rawhide (December 23th package list) using
gcc-4.7.0-0.1.fc17 on x86_64, and for those packages that failed also
rebuilt the same package with gcc-4.6.2-1.fc16 to quickly remove from the
list packages that fail for non-gcc related reasons.
Out of the 11270 packages I've built, 10056 packages built fine with
gcc-4.7.0-0.1.fc17 and 845 packages failed to build also with
gcc-4.6.2-1.fc16, so I'm ignoring those from any analysis.
I've analyzed some of the remaining failures and tried to categorize it
a little bit. There were 3 internal compiler errors seen during the
whole mass rebuild, http://gcc.gnu.org/PR5169{2,4,5} are currently
filed and slightly analyzed, but not fixed yet.

CCing Benjamin if he'd be interested to write
http://gcc.gnu.org/gcc-4.7/porting_to.html again this time.

The common reasons for build failures were (I'm attaching srpm lists for
these categories):

http://gcc.gnu.org/PR49745 119 failures
<iostream>, <string> and other STL headers that previously
included <unistd.h> as an implementation detail (to get some
feature macros for gthr*.h purposes) no longer do so (it was
a C++ standard violation), to fix this up just add
#include <unistd.h> early in the sources (or headers) that need it.

http://gcc.gnu.org/PR24163 60 failures
http://gcc.gnu.org/PR29131 28 failures
C++ lookup fixes, the C++ FE no longer performs an extra unqualified
lookup that it (incorrectly) performed in the past. In some cases the
diagnostics includes hints how to fix the bugs, for PR24163 the
diagnostics looks like:
error: 'something' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
note: declarations in dependent base 'someclass<somearg>' are not found by unqualified lookup
note: use 'this->something' instead
and for PR29131 diagnostics looks like:
error: 'something' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
note: 'template<class T1, class T2> sometype something(T1&, const T2&)' declared here, later in the translation unit

checking for stdbool.h that conforms to C99... no 2 failures
but affects other 150+ packages
apparently autoconf 2.60 through autoconf 2.67 contains an invalid
check in its stdbool.h checking macro:
# if defined __xlc__ || defined __GNUC__
/* Catch a bug in IBM AIX xlc compiler version 6.0.0.0
reported by James Lemley on 2005-10-05; see
http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html
This test is not quite right, since xlc is allowed to
reject this program, as the initializer for xlcbug is
not one of the forms that C requires support for.
However, doing the test right would require a runtime
test, and that would make cross-compilation harder.
Let us hope that IBM fixes the xlc bug, and also adds
support for this kind of constant expression. In the
meantime, this test will reject xlc, which is OK, since
our stdbool.h substitute should suffice. We also test
this with GCC, where it should work, to detect more
quickly whether someone messes up the test in the
future. */
char digs[] = "0123456789";
int xlcbug = 1 / (&(digs + 5)[-2 + (bool) 1] == &digs[4] ? 1 : -1);
# endif
As written, the test is not quite right and a conforming C compiler
is not required to accept it and starting with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172958
GCC rejects it (and similarly from what I understood from autoconf
2.68 notes recent xlc rejects it as well). autoconf 2.68 dropped
this incorrect check, but apparently many packages include their
own configure scripts without regenerating them. Wonder what is the
best thing to do here, ask package maintainers to grep for this
int xlcbug = ...; in their packages and sedding that to
int xlcbug = 0;, or dropping that || defined __GNUC__ above the
invalid test, or asking where possible to regenerate configure with
autoconf 2.68, perhaps some rpm-build script to do the sedding?
Most of the 150+ packages just refused to use the system <stdbool.h>
because of this and did something else (either provided their own
stdbool.h alternative, falled back to using int instead of bool,
...), the 2 failures were just cases where this was a fatal failure.

https://svn.boost.org/trac/boost/ticket/6165 26 failures
Apparently boost uses some libstdc++-v3 internal macros to determine
if gcc has been configured with or without thread support, in GCC 4.7
these internal macros changed and boost thinks GCC 4.7.0 no longer
supports threads (e.g. in libstdc++ headers). The fix here will be
just to fix up boost package we include.

gcc driver became more picky about
bogus options during linking 14 failures
GCC 4.6 and earlier apparently didn't complain about completely
invalid options on gcc/g++/gfortran etc. command lines, if
nothing was compiled, but only linking was performed.
E.g. gcc -Wl -o foo foo.o -mflat_namespace
would work just fine, even when -Wl needs to have some option
to pass to the linker after it and -mflat_namespace isn't supported
at all. Garbage options just need to be removed from the command
line or replaced by something that is actually supported.

http://gcc.gnu.org/PR2288 8 failures
For C++, GCC 4.6 and earlier incorrectly put the two
declarations in different scopes in cases like:
for (int i = 0; i < 10; i++)
{
int i = 2;
}
While that is valid C99 (where there is a separate scope
with the for declared vars and { int i = 2; } is another scope
inside it), in C++ this is invalid, the int i = 0; declaration
goes into the same scope as the body of the for cycle (similarly
for if/switch). To fix this, either rename one of the decls,
or if you really meant to have the same name and want to have
them in different scopes, add another pair of {}s around the body.
With
for (int i = 0; i < 10; i++)
{{
int i = 2;
}}
the inner {} is already a nested scope.

user defined literal support 3 failures
When compiling C++ with -std={c++11,c++0x,gnu++11,gnu++0x} GCC 4.7.0
unlike older versions supports user defined literals, which are
incompatible with some valid ISO C++03 code.
In particular, whitespace is now needed after a string literal
before something that could be a valid user defined literal.
Say const char *p = "foobar"__TIME__; is valid C++03, the __TIME__
macro expands to some string literal and is concatenated with the
other one. In C++11 __TIME__ isn't expanded, instead operator ""
__TIME__ is being looked up. This applies to any string literal
followed without whitespace by some macro. Just add some whitespace
between the string literal and the macro name.

-Werror 12 failures
As usually, packages compiled with -Werror sometimes fail because
newer GCC versions emit slightly different warnings (could be
correct warnings, newly introduced warnings, could be even false
positives, but with -Werror you need to be prepared to workaround
them).

libgcj 6 failures
gcc-4.7.0-0.1.fc17 contained a packaging bug for libgcj, the
libgcj.so symlink incorrectly pointed to libgcj.so.12 instead
of libgcj.so.13. Will fix this for -0.2.fc17, to this category
I've also included package failures where non-indirect-dispatch
gcj built packages failed to build due to their dependencies
not finding libgcj.so.12 dependency. Those will just need to
be rebuilt.

unanalyzed 91 failures
Ran out of time, haven't analyzed the remaining ones (other
category), once gcc-4.7.0-0.*.fc17 hits the buildroots,
please try to analyze these. Could be gcc bugs, but could
very well be package bugs. E.g. in glibc (which built fine,
just failed a couple of tests that previously succeeded),
I've discovered it was a glibc bug:
http://sources.redhat.com/ml/libc-alpha/2011-12/msg00091.html

Jakub
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20111231/fd944266/attachment.html>
Jakub Jelinek
2011-12-31 15:35:00 UTC
Permalink
Post by Dennis Gilmore
if we plan to do a mass rebuild for gcc 4.7 we need to start it next week.
IMHO a mass rebuild is highly desirable, but (with the exception of
a few gcj/objc dependent packages not strictly required). We still have
lots of *.fc15, and we even have some *.fc11 packages.
That said, why would it need to start next week? Looking at the F15
schedule where a mass rebuild has been performed too on Feb, 7th or so,
the schedule milestones are the same.

I can put gcc-4.7.0-0.2.fc17 say mid next week into the buildroots,
but would strongly prefer to have it there for at least two weeks
of voluntary rebuilds, so that there is enough time to report bugs
and get them fixed, before a real mass rebuild starts.
So, if at all possible, I'd prefer the mass rebuild to start around January
19th or 20th. That's still before Feature Submission Deadline and more than
three weeks before Alpha deadline.

Jakub
Bruno Wolff III
2011-12-31 15:53:24 UTC
Permalink
On Sat, Dec 31, 2011 at 16:35:00 +0100,
Post by Jakub Jelinek
Post by Dennis Gilmore
if we plan to do a mass rebuild for gcc 4.7 we need to start it next week.
IMHO a mass rebuild is highly desirable, but (with the exception of
a few gcj/objc dependent packages not strictly required). We still have
lots of *.fc15, and we even have some *.fc11 packages.
That said, why would it need to start next week? Looking at the F15
schedule where a mass rebuild has been performed too on Feb, 7th or so,
the schedule milestones are the same.
That rebuild caused problems. I think we'd want the rebuild essebtially
completed before branching.
https://fedoraproject.org/wiki/Fedora_15_QA_Retrospective has some issues
noted that were affected by the mass rebuild being so close to the
branch.
Peter Robinson
2011-12-31 16:25:06 UTC
Permalink
Post by Jakub Jelinek
Post by Dennis Gilmore
if we plan to do a mass rebuild for gcc 4.7 we need to start it next week.
IMHO a mass rebuild is highly desirable, but (with the exception of
a few gcj/objc dependent packages not strictly required).  We still have
lots of *.fc15, and we even have some *.fc11 packages.
That said, why would it need to start next week?  Looking at the F15
schedule where a mass rebuild has been performed too on Feb, 7th or so,
the schedule milestones are the same.
It should be complete before branching because otherwise it would have
to happen twice, once on rawhide (F18) and one of the F17 branch.

F15 packages are not surprising as there wasn't a mass rebuild during
F16. There were a number of packages that were broken and not
rebuilt/fixed as part of the f15 mass rebuild which should have been.
Post by Jakub Jelinek
I can put gcc-4.7.0-0.2.fc17 say mid next week into the buildroots,
but would strongly prefer to have it there for at least two weeks
of voluntary rebuilds, so that there is enough time to report bugs
and get them fixed, before a real mass rebuild starts.
So, if at all possible, I'd prefer the mass rebuild to start around January
19th or 20th.  That's still before Feature Submission Deadline and more than
three weeks before Alpha deadline.
We branch a week before alpha though, the schedule for branching is
Feb 7th so you'd want to have it complete well before then just in
case there's issues that need to be fixed. It should really be
complete before the end of Jan to give breathing room for all
involved.

Peter
Tomasz Torcz
2011-12-31 18:21:39 UTC
Permalink
Post by Peter Robinson
Post by Jakub Jelinek
Post by Dennis Gilmore
if we plan to do a mass rebuild for gcc 4.7 we need to start it next week.
IMHO a mass rebuild is highly desirable, but (with the exception of
a few gcj/objc dependent packages not strictly required).  We still have
lots of *.fc15, and we even have some *.fc11 packages.
That said, why would it need to start next week?  Looking at the F15
schedule where a mass rebuild has been performed too on Feb, 7th or so,
the schedule milestones are the same.
It should be complete before branching because otherwise it would have
to happen twice, once on rawhide (F18) and one of the F17 branch.
We branch a week before alpha though, the schedule for branching is
Feb 7th so you'd want to have it complete well before then just in
case there's issues that need to be fixed. It should really be
complete before the end of Jan to give breathing room for all
involved.
By The Way, the UsrMove feature may involve rebuild also. Last time
I chatted about this, people involved were planning on fixing packages
globally.
--
Tomasz Torcz There exists no separation between gods and men:
xmpp: zdzichubg at chrome.pl one blends softly casual into the other.
Dennis Gilmore
2012-01-01 02:45:10 UTC
Permalink
El Sat, 31 Dec 2011 16:35:00 +0100
Post by Jakub Jelinek
Post by Dennis Gilmore
if we plan to do a mass rebuild for gcc 4.7 we need to start it next week.
IMHO a mass rebuild is highly desirable, but (with the exception of
a few gcj/objc dependent packages not strictly required). We still
have lots of *.fc15, and we even have some *.fc11 packages.
That said, why would it need to start next week? Looking at the F15
schedule where a mass rebuild has been performed too on Feb, 7th or
so, the schedule milestones are the same.
I can put gcc-4.7.0-0.2.fc17 say mid next week into the buildroots,
but would strongly prefer to have it there for at least two weeks
of voluntary rebuilds, so that there is enough time to report bugs
and get them fixed, before a real mass rebuild starts.
So, if at all possible, I'd prefer the mass rebuild to start around
January 19th or 20th. That's still before Feature Submission
Deadline and more than three weeks before Alpha deadline.
Jakub
[ausil at download01 ~]$ ls /srv/pub/fedora/linux/development/rawhide/source/SRPMS/*fc11.src.rpm|wc -l
3
[ausil at download01 ~]$ ls /srv/pub/fedora/linux/development/rawhide/source/SRPMS/*fc12.src.rpm|wc -l
59
[ausil at download01 ~]$ ls /srv/pub/fedora/linux/development/rawhide/source/SRPMS/*fc13.src.rpm|wc -l
19
[ausil at download01 ~]$ ls /srv/pub/fedora/linux/development/rawhide/source/SRPMS/*fc14.src.rpm|wc -l
44
[ausil at download01 ~]$ ls /srv/pub/fedora/linux/development/rawhide/source/SRPMS/*fc15.src.rpm|wc -l
3334
[ausil at download01 ~]$ ls /srv/pub/fedora/linux/development/rawhide/source/SRPMS/*fc16.src.rpm|wc -l
3140
[ausil at download01 ~]$ ls /srv/pub/fedora/linux/development/rawhide/source/SRPMS/*fc17.src.rpm|wc -l
4415

those older than f15 either need fixing or dropping. but thats another
issue. branching is sceduled for feb 7. 4 weeks before that is Jan 10.
thats the latest we could start. it will take ~ 1 week to build
everything. then we have 3 weeks to fix whats broken and failed to
build. we really rushed the f15 mass rebuild and it caused extra pain.
pain we should avoid. Sorry I did not respond earlier I jumped in the
car for a 800km drive right after sending my last email.

so, the question then becomes if we can get it in early this week, we
could probably give 2 weeks for voluntary building then force the
rebuild for the rest and give 2 weeks clean up. f15 we did not allow
for voluntary rebuilds before releng stepped in and did them. we also
did not allow for opt out of f15 due to the very tight schedule. I
really want to avoid it being tight. we really probably should have
had this land before christmas. how well tested is 4.7 on the secondary
arches?


Dennis
Ville Skyttä
2011-12-31 16:43:33 UTC
Permalink
Post by Jakub Jelinek
gcc-4.7.0-0.1.fc17 on x86_64
Is this package available somewhere?
Tom Lane
2011-12-31 16:51:55 UTC
Permalink
Post by Ville Skyttä
Post by Jakub Jelinek
gcc-4.7.0-0.1.fc17 on x86_64
Is this package available somewhere?
It'd be a lot easier for packagers to work on fixing their packages for
it if there were a build available for F16.

regards, tom lane
Nils Philippsen
2012-01-02 12:30:11 UTC
Permalink
Post by Jakub Jelinek
Hi!
As part of preparations to switch GCC in F17 to GCC 4.7.0, I've performed
a test mass rebuild of rawhide (December 23th package list) using
gcc-4.7.0-0.1.fc17 on x86_64, and for those packages that failed also
rebuilt the same package with gcc-4.6.2-1.fc16 to quickly remove from the
list packages that fail for non-gcc related reasons.
Out of the 11270 packages I've built, 10056 packages built fine with
gcc-4.7.0-0.1.fc17 and 845 packages failed to build also with
gcc-4.6.2-1.fc16, so I'm ignoring those from any analysis.
I've attached a list of packages and (co)maintainers, to easily find if
one of your packages is affected or not.

Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils at redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
-------------- next part --------------
3Depict: mycae
4ti2: tremble
activemq-cpp: stevetraylen
adanaxisgpl: jwrdegoede
alliance: chitlesh - chitlesh,tnorth
alure: guidograzioli - julian
anthy: tagoh
aplus-fsf: s4504kr
apt: athimm - pmatilai
aqsis: kwizart - pmachata
aria2: sundaram
armacycles-ad: limb
arpage: verdurin
asc: jwrdegoede
audacious-plugins: mschwendt - atkac
aunit: landgraf
avr-gcc: tnorth - ndim,trondd
bangarang: jreznik
barry: gnat - gnat
bes: orion - pertusus
bibletime: deji - deji
binutils: nickc - aoliva,jakub,jankratochvil,nickc
blahtexml: jasper
blender: s4504kr - kwizart,roma
blobby: sundaram - ankursinha
bluez: hadess - dwmw2
boolstuff: konradm - pertusus
boost141: robert
boost: bkoz - denisarnaud,pmachata
bowtie: verdurin
btanks: bruno - bruno
cairo-java: orphan
calf: oget
cantor: than - jreznik,kkofler,ltinkl,rdieter,rnovacek
cegui: jwrdegoede - bruno,mpreisle
ceph: josef - boodle,jdieter,ke4qqq,steve,stingray
clamav: ensc - nb(?)
ClanLib: jwrdegoede
clisp: jjames - green,jjames
clucene: deji - jreznik(?),rdieter
cmake: orion - jreznik,pertusus,rdieter
codeblocks: sharkcz
code-editor: ilyes
Coin2: corsepiu
conexus: rvinyard
coot: timfenn
cppad: bradbell
cppcheck: jussilehtola - scop
CriticalMass: jwrdegoede
cryptkeeper: hicham
cryptopp: sundaram - nucleo
CTL: kwizart
curblaster: limb
cyphesis: wart - bruno
dbus-cxx: rvinyard
dcmtk: mrceresa
dopewars: jussilehtola
eigen2: rdieter - kkofler
elfutils: roland - aoliva,fche(?),jakub,mjw,pmachata
ember: bruno - bruno,wart
esteid-browser-plugin: kalev
ETL: lkundrak
fastx_toolkit: verdurin
fatrat: jvcelak
faust: oget
fawkes: timn - rmattes
festival: davidz - ajax,alexl,caillon,caolanm,hadess,johnp,jrb,mattdm,mbarnes,mclasen,rhughes,rnorwood,rstrode,ssp,timn
Field3D: hobbes1069
fife: cassmodiah - bruno
filezilla: kwizart
florist: landgraf
flush: avienda
fmt-ptrn: mikep
freeciv: limb
freefem++: rathann - itamarjp
freenx-client: athimm
frepple: jdetaeye
frysk: cagney - kasal,mjw,pmuldoon
fusecompress_offline1: toshio - lkundrak,lmacken
fwbuilder: ertzing
gccxml: ellert
gdisk: terjeros
gearbox: rmattes
gearmand: derks - derks
gfan: konradm - jjames
gforth: adrian
gigolo: kevin
ginac: rakesh - rakesh
git: chrisw - atkac(?),jbowes,npajkovs(?),tmz
givaro: mycae - jjames
glest: bruno
glob2: bruno - cheese(?)
glom: hguemar
gnash: hicham - jreznik,pertusus
gnatcoll: landgraf
gnome-commander: mtasaka
gnomeradio: rathann - itamarjp
gnome-schedule: sundaram
gnome-subtitles: belegdol
gnuplot: pschiffe
gnuradio: mmahut - jskarvad
gnustep-back: s4504kr
gnustep-base: s4504kr
gnustep-examples: s4504kr
gnustep-gui: s4504kr
goldendict: helloworld1
gorm: s4504kr
gource: siddhesh
gprbuild: landgraf
grantlee: rdieter - rdieter,than
grass: devrim - devrim(?),oliver(?),pertusus,rezso(?),volter
grub2: pjones - ausil,pjones
gsmartcontrol: brouhaha
gst123: siddhesh
gtkmathview: uwog
guimup: th0br0
gwenhywfar: notting
hamster-applet: maxx
hercstudio: sharkcz
hotssh: walters
hugin: bpostle - denisarnaud
icc_examin: kwizart
ice: hguemar
icu: erack - ajax,alexl,caillon,davidz,erack,hadess,johnp,jrb,mbarnes,mclasen,rhughes,rnorwood,rstrode,ssp
incron: ruben
inkscape: lkundrak - duffy,lkundrak
Inventor: corsepiu
isomd5sum: anaconda-maint - clumens,rvykydal,skvidal(?)
iwhd: meyering - clalance,zaitcev
jaffl: mmorsi
java-1.6.0-openjdk: dbhole - dbhole,jvanek,omajid
java-1.7.0-openjdk: dbhole - jvanek,omajid
jffi: mmorsi
jnr-ffi: mmorsi
k3d: corsepiu
kaffeine: kkofler - mef,rdieter
kaya: s4504kr
kdebase-workspace: than - jreznik,kkofler,ltinkl,nucleo,rdieter,rnovacek,rrix,svahl
kdegames: than - jreznik,kkofler,ltinkl,rdieter,rnovacek,rrix,svahl
kdelibs3: than - kkofler,ltinkl,rdieter
kdelibs: than - jreznik,kkofler,ltinkl,rdieter,rnovacek,rrix
kdemultimedia: than - jreznik,kkofler,ltinkl,rdieter,rnovacek
kdenetwork: than - jreznik,kkofler,ltinkl,nucleo,rdieter,rnovacek
kdepim3: rdieter - ovasik,rnovacek
kdepim: than - jreznik,kkofler,ltinkl,rdieter,rnovacek
kdevelop-php: rdieter - kkofler,ltinkl,rnovacek,than
keepassx: abompard
kicad: dionysos - chitlesh,dionysos,tnorth
kid3: scop
klatexformula: nucleo
kmplayer: rdieter - oget
komparator: nbecker
koverartist: svahl
krb5: nalin
krecipes: ausil
krusader: rnovacek - kkofler
kvirc: nucleo
ldc: bioinfornatics
libconcord: silfreed
libdigidocpp: kalev - anttix,tuju
libffado: oget - bsjones
libfreebob: green
libfwbuilder: ertzing
libgconf-java: orphan
libglade-java: orphan
libjingle: spot - spot(?)
libkml: rakesh
libkni3: timn
libmnetutil: peter
libmsn: john5342 - ltinkl,rdieter,tuxbrewr
libofa: rdieter - than
libofx: notting
librep: kimheino
libtpms: stefanberger
libvoikko: vpv
libvpd: emunson - jskala
libvte-java: orphan
libwvstreams: msekleta - jsynacek
linbox: jjames
linphone: rakesh - nucleo,rishi(?)
llvm: salimma - bos,dmalcolm,salimma
lmms: thm
lordsawar: bruno - bruno
LuxRender: kwizart
lyx: rdieter - jamatos
matahari: arjunroy - astokes,beekhof,mcpierce,nsantos,russellb,zaneb
matreshka: landgraf
mdadm: dledford - agk,jsorensen,mbroz
mediatomb: rmattes
medusa: jfch2222
memcached: plindner - jorton,mlichvar,ruben,thias
mercator: wart - bruno
meshlab: brouhaha
meshmagick: bruno - bruno
mimetic: ensc
minetest: bookwar
mingw32-gcc: rjones - kalev
mingw32-nsis: rjones - kkofler,lfarkas
mingw-gtk3: kalev - epienbro
minicomputer: verdurin
minion: alexises
minitunes: skytux
mldonkey: peter - rjones
mm3d: sharkcz
mozc: tagoh
mrpt: jlblanco - rmattes(?)
mumble: th0br0 - jgold
muse: oget - nando
mygui: bruno - bruno
mysql: tgl - atkac(?),hhorak
ncmpcpp: dmaphy
nekovm: rjones
netpanzer: limb - laxathom
newsbeuter: mathstuf
nted: orphan
numptyphysics: lkundrak
nurbs++: mycae
octave: rakesh - alexlan,jussilehtola,mmahut,orion,rakesh
octave-signal: sailer
octave-symbolic: sailer
oggvideotools: maxamillion - maxamillion
ogre: bruno - bruno,dtimms
ogre-pagedgeometry: bruno - bruno
ois: bruno - bruno
olpc-powerd: pgf - martinlanghoff
ompl: rmattes
openbabel: rathann - itamarjp
openCOLLADA: hobbes1069
openlierox: jwrdegoede
openscada: aleksey2005
openscap: pvrabec - mildew,theinric
openslide: agoode
openswan: avesh - sgrubb
openttd: heffer
openvpn-auth-ldap: thias
ORBit2: mclasen - ajax,alexl,caillon,caolanm,davidz,hadess,johnp,jrb,mbarnes,rhughes,rnorwood,rstrode,ssp
ovaldi: lkundrak - mbarabas
paraview: orion - deji,pertusus
pdftk: s4504kr - oget
pdns: ruben
perl-Cache-Cache: steve
perl-Qt: iarnell
php-pear-Cache-Lite: remi
pianobooster: chkr
piklab: chitlesh - dionysos,tnorth
pingus: limb
pion-net: jvcelak
player: timn - rmattes
plplot: orion
podofo: sharkcz
pokerth: rrix
posterazor: eponyme
powertop: jskarvad - sundaram(?)
protobuf: abbot - derks,jlaska,konradm
psi: slankes - slankes
pulseaudio: lennart - bsjones(?),jkratoch(?),lkundrak,rdieter(?)
pure: salimma
pxe-kexec: boodle
pycryptopp: ruben
python-gnutls: peter
python-logilab-common: bcl - mrunge
python-polybori: konradm - jjames
python-robofab: pnemade
python-visual: tomspur
qalculate-kde: deji
qbittorrent: leigh123linux
qca2: slankes - slankes
qpid-cpp: nsantos - nsantos
qt-creator: itamarjp - hiemanshu,ltinkl,rdieter(?)
qterm: cheeselee
qt-mobility: rdieter - heliocastro,kkofler,than
qtsingleapplication: oget
qtwebkit: rdieter - jreznik,than
qutim: hubbitus
rafkill: limb
ragel: jjh
raidem: laxathom - bruno
raul: davidcornette
rawtherapee: tnorth - hpejakle,sdz
rb_libtorrent: sundaram - leigh123linux
rcssserver3d: hedayat
rekall: spot
rinputd: jwilson
rmol: denisarnaud - denisarnaud
root: ellert
rosegarden4: seg - bsjones,oget
rubygem-ffi: bkearney
rubygem-json: laxathom - clalance(?),mfojtik(?),mkent(?),stahnma,vondruch(?)
rubygem-rerun: mfojtik - vondruch
sblim-wbemcli: vcrhonek
schroot: zachcarter
scilab: davidcl
scim-bridge: pwu - petersen,pwu
scim-fcitx: pwu
scim-hangul: petersen - ueno
scorched3d: jwrdegoede - bruno
seamonkey: gecko-maint - caillon,kengert
sear: wart - bruno
sems: peter - itamarjp(?),ondrejj
simspark: hedayat
sipwitch: dyfet - nucleo
skychart: sergiopr - mmahut
smartcardpp: kalev - anttix,tuju
sonic-visualiser: salimma - rakesh(?)
soprano: rdieter - jreznik,kkofler,ltinkl,than
spectrum: mcepl - jkaluza
sphinx: cdamian
spicebird: tuxbrewr
spor: aquini
springlobby: gilboa
sqlite: pmatilai
squid: jskala - hno,jskala,jsteffan
squirrel: sharkcz
stp: jjames - amdunn
strace: roland - ldv,schwab,vda
strigi: deji - kkofler,ltinkl,rdieter
sudoku-savant: mariobl
sunpinyin: liangsuilong - helloworld1,pwu
svxlink: lucilanga
swift: jkaluza
sword: deji
synaptic: athimm - pmatilai
synfigstudio: lkundrak - luya
systemtap: fche - drsmith2,jistone,mjw,scox,wcohen
tamil-typing-booster: pravins
task: ultrafredde
tcltls: tjikkun
telepathy-qt4: jreznik - rdieter
tellico: jamatos - alexlan
tesseract: karlik
thunderbird: gecko-maint - ajax,alexl,caillon,caolanm,davidz,johnp,jrb,kengert,mbarnes,mclasen,rhughes,rstrode,ssp,stransky,xhorak
thunderbird-lightning: orion
tncfhh: avesh
travelccm: denisarnaud
tripwire: tuxbrewr
tuxcmd: tbzatek
uhd: jskarvad
ultimatestunts: sharkcz
uncrustify: nbecker
UnihanDb: dchen
urg: timn
v8: orphan
valknut: mjakubicek - mjakubicek
vdr: scop - vpv
vdr-epgsearch: scop - vpv
vdr-streamdev: heffer
vdr-sudoku: scop
vdr-ttxtsubs: scop
vdr-wapd: scop
vegastrike: jwrdegoede - bruno
vfrnav: sailer
vigra: bpostle
vios-proxy: nsantos
vym: limb
webkitgtk: kevin - huzaifas,kevin,mso
webkitgtk3: mclasen
wfmath: wart - bruno
wfut: wart - bruno
wpa_supplicant: dcbw
xbase: spot
xdrawchem: rathann - itamarjp
xemacs: jjames
xmoto: limb
xqilla: hguemar - nsantos
xsd: anttix
xsupplicant: spot
xxdiff: cattelan
zoneminder: mebourne - tibbs
zorba: mgieseki
Nathanael Noblet
2012-01-02 16:09:29 UTC
Permalink
Post by Nils Philippsen
I've attached a list of packages and (co)maintainers, to easily find if
one of your packages is affected or not.
Hello,

It seems one of my packages has an issue, the gcc unistd.h include one. How do I reproduce the build issues? Is there a package someplace or mock config I can use to test it out to make sure I have it working/patched? Do I need to use my own repos with an unsigned build of gcc from koji? Or will there be a global repo people can use prior to the mass rebuild? Or should I just wait for the mass rebuild and do it then etc??

Thanks,
--
Nathanael d. Noblet
Jakub Jelinek
2012-01-02 17:14:57 UTC
Permalink
Post by Nathanael Noblet
Post by Nils Philippsen
I've attached a list of packages and (co)maintainers, to easily find if
one of your packages is affected or not.
It seems one of my packages has an issue, the gcc unistd.h include one.
How do I reproduce the build issues? Is there a package someplace or mock
config I can use to test it out to make sure I have it working/patched?
Do I need to use my own repos with an unsigned build of gcc from koji? Or
will there be a global repo people can use prior to the mass rebuild? Or
should I just wait for the mass rebuild and do it then etc??
Just wait an extra day or two.

Jakub
Jim Meyering
2012-01-02 18:03:44 UTC
Permalink
Nils Philippsen wrote:
...
Post by Nils Philippsen
I've attached a list of packages and (co)maintainers, to easily find if
one of your packages is affected or not.
...
Post by Nils Philippsen
iwhd: meyering - clalance,zaitcev
Thank you for the list.

I have just tried to build iwhd on F16 using a pretty recent gcc-4.7.x
(built manually: 4.7.0 20111202), and it worked fine, so I'm not quite
sure why iwhd is on the list. Maybe the gcc-4.7.x that Jakub used
lacks something that's in my Dec 2 snapshot, or maybe it's simply a
problem in a dependent that has been fixed in the interim.

Oh!!! I see it.
The tested version (the one in rawhide) is iwhd-1.1,
while the latest is 1.2 (which is in F16). Shame on me
for not putting the latest also in rawhide.

Is there some sort of reminder service that could be configured
to nag the maintainers of a package in a situation like this?
Personally, I would appreciate it, and I think Fedora would
benefit if we could do something to minimize reverse-version
skew between Fedora-latest and rawhide.

Even if it's just a weekly posting of offenders to fedora-devel,
so people know it's an issue...
Pádraig Brady
2012-01-03 12:16:56 UTC
Permalink
Post by Jim Meyering
...
Post by Nils Philippsen
I've attached a list of packages and (co)maintainers, to easily find if
one of your packages is affected or not.
...
Post by Nils Philippsen
iwhd: meyering - clalance,zaitcev
Thank you for the list.
I have just tried to build iwhd on F16 using a pretty recent gcc-4.7.x
(built manually: 4.7.0 20111202), and it worked fine, so I'm not quite
sure why iwhd is on the list. Maybe the gcc-4.7.x that Jakub used
lacks something that's in my Dec 2 snapshot, or maybe it's simply a
problem in a dependent that has been fixed in the interim.
Oh!!! I see it.
The tested version (the one in rawhide) is iwhd-1.1,
while the latest is 1.2 (which is in F16). Shame on me
for not putting the latest also in rawhide.
Is there some sort of reminder service that could be configured
to nag the maintainers of a package in a situation like this?
Personally, I would appreciate it, and I think Fedora would
benefit if we could do something to minimize reverse-version
skew between Fedora-latest and rawhide.
Even if it's just a weekly posting of offenders to fedora-devel,
so people know it's an issue...
I recently tried to add an F16 update without having the build in rawhide,
and the update was rejected, saying the last built version in rawhide
was older. I used the web interface to generate the update, but surely
that logic is not just in the web interface?

cheers,
Pádraig.
Peter Robinson
2012-01-03 14:11:50 UTC
Permalink
Post by Pádraig Brady
Post by Jim Meyering
...
Post by Nils Philippsen
I've attached a list of packages and (co)maintainers, to easily find if
one of your packages is affected or not.
...
Post by Nils Philippsen
iwhd: meyering - clalance,zaitcev
Thank you for the list.
I have just tried to build iwhd on F16 using a pretty recent gcc-4.7.x
(built manually: 4.7.0 20111202), and it worked fine, so I'm not quite
sure why iwhd is on the list.  Maybe the gcc-4.7.x that Jakub used
lacks something that's in my Dec 2 snapshot, or maybe it's simply a
problem in a dependent that has been fixed in the interim.
Oh!!! I see it.
The tested version (the one in rawhide) is iwhd-1.1,
while the latest is 1.2 (which is in F16).  Shame on me
for not putting the latest also in rawhide.
Is there some sort of reminder service that could be configured
to nag the maintainers of a package in a situation like this?
Personally, I would appreciate it, and I think Fedora would
benefit if we could do something to minimize reverse-version
skew between Fedora-latest and rawhide.
Even if it's just a weekly posting of offenders to fedora-devel,
so people know it's an issue...
I recently tried to add an F16 update without having the build in rawhide,
and the update was rejected, saying the last built version in rawhide
was older.  I used the web interface to generate the update, but surely
that logic is not just in the web interface?
Completely off topic to this thread but you should really build in
rawhide first, and then F16. The logic should be on the back end so be
the same whether its web or cli updates.

Peter
Jan Kratochvil
2012-01-03 14:07:25 UTC
Permalink
Post by Jim Meyering
The tested version (the one in rawhide) is iwhd-1.1,
while the latest is 1.2 (which is in F16). Shame on me
for not putting the latest also in rawhide.
If you never do a build in Rawhide - your latest build is the F16 one
- Rawhide automatically inherits the F16 (or older) builds.
I find it useful.

Once you do a first Rawhide build I do not know how to revert it.


Regards,
Jan
Ville Skyttä
2012-01-04 20:22:21 UTC
Permalink
Post by Jan Kratochvil
If you never do a build in Rawhide - your latest build is the F16 one
- Rawhide automatically inherits the F16 (or older) builds.
I find it useful.
Me too, but beware, sometimes the inheritance is explicitly disabled.
http://lists.fedoraproject.org/pipermail/devel/2011-January/147592.html
Post by Jan Kratochvil
Once you do a first Rawhide build I do not know how to revert it.
In my experience inheritance starts to work again after the next
release. So if you built for f17 rawhide, when rawhide becomes f18 it
starts to pull in f17 stuff again.
Toshio Kuratomi
2012-01-04 21:01:00 UTC
Permalink
Post by Ville Skyttä
Post by Jan Kratochvil
If you never do a build in Rawhide - your latest build is the F16 one
- Rawhide automatically inherits the F16 (or older) builds.
I find it useful.
Me too, but beware, sometimes the inheritance is explicitly disabled.
http://lists.fedoraproject.org/pipermail/devel/2011-January/147592.html
Dennis has talked about explicitly disabling inheritance at a certain point
in the cycle (maybe even when we branch) so that this is more predictable
but I don't think it's gotten out of the "thinking about it" stage.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120104/0b533553/attachment.sig>
Kevin Kofler
2012-01-05 00:09:39 UTC
Permalink
Post by Jan Kratochvil
Once you do a first Rawhide build I do not know how to revert it.
Untag all the Rawhide builds with koji untag-pkg f17 NVR.

Be warned that rel-eng is going to yell at you if you do this without
ensuring that the EVR inherited from F16 is newer. FESCo decided that EVRs
are not supposed to go backwards, even in Rawhide (which I think is a quite
silly policy for Rawhide, but that's what that time's FESCo decided and
hasn't been overturned since).

Kevin Kofler
Jakub Jelinek
2012-01-03 14:39:55 UTC
Permalink
Post by Jim Meyering
I have just tried to build iwhd on F16 using a pretty recent gcc-4.7.x
(built manually: 4.7.0 20111202), and it worked fine, so I'm not quite
sure why iwhd is on the list. Maybe the gcc-4.7.x that Jakub used
lacks something that's in my Dec 2 snapshot, or maybe it's simply a
problem in a dependent that has been fixed in the interim.
iwhd was in the totally non-analyzed lists, which built normally
in rawhide x86_64 mock and failed to build with
that plus my gcc 4.7.0 + libtool repo.
The failure was:
checking gc.h presence... yes
checking for gc.h... yes
checking for mongo/client/dbclient.h... no
configure: error: Missing Mongo DB client development library: mongodb-devel
error: Bad exit status from /var/tmp/rpm-tmp.ndPEGn (%build)
Bad exit status from /var/tmp/rpm-tmp.ndPEGn (%build)
RPM build errors:
Child returncode was: 1

Given the huge amount of packages, I really don't have time to look
at every one, the mass rebuild was performed mainly to determine
gcc 4.7 readiness and find out most common porting issues when porting
from 4.6 to 4.7. The rebuilds were all done using mock, while with the
same set of package NVRs (taken from 23rd SRPMS list), the rawhide distro
could very well be slightly changing even over the period of the few
days it took to rebuild everything.

BTW, the stdbool configury problem I wrote about is solved on the
gcc side, we optimize again the (not strictly valid) test and thus
the standard autoconf 2.6[0-7] stdbool detection should work again.

Jakub
Jim Meyering
2012-01-03 20:58:29 UTC
Permalink
Post by Jakub Jelinek
Post by Jim Meyering
I have just tried to build iwhd on F16 using a pretty recent gcc-4.7.x
(built manually: 4.7.0 20111202), and it worked fine, so I'm not quite
sure why iwhd is on the list. Maybe the gcc-4.7.x that Jakub used
lacks something that's in my Dec 2 snapshot, or maybe it's simply a
problem in a dependent that has been fixed in the interim.
iwhd was in the totally non-analyzed lists, which built normally
in rawhide x86_64 mock and failed to build with
that plus my gcc 4.7.0 + libtool repo.
checking gc.h presence... yes
checking for gc.h... yes
checking for mongo/client/dbclient.h... no
configure: error: Missing Mongo DB client development library: mongodb-devel
error: Bad exit status from /var/tmp/rpm-tmp.ndPEGn (%build)
Bad exit status from /var/tmp/rpm-tmp.ndPEGn (%build)
Child returncode was: 1
Hi Jakub,

Thanks for the details.
Sorry if my post made it look like a request for
more information from you. At first, it was -- sort of --
but then I realized and explained that it was my own problem
for not putting the latest iwhd in rawhide.
Post by Jakub Jelinek
Given the huge amount of packages, I really don't have time to look
at every one, the mass rebuild was performed mainly to determine
gcc 4.7 readiness and find out most common porting issues when porting
from 4.6 to 4.7. The rebuilds were all done using mock, while with the
same set of package NVRs (taken from 23rd SRPMS list), the rawhide distro
could very well be slightly changing even over the period of the few
days it took to rebuild everything.
BTW, the stdbool configury problem I wrote about is solved on the
gcc side, we optimize again the (not strictly valid) test and thus
the standard autoconf 2.6[0-7] stdbool detection should work again.
Thanks for all the work.
Denis Arnaud
2012-01-03 14:24:26 UTC
Permalink
Hi Jim,

2012/1/3 <devel-request at lists.fedoraproject.org>
Is there some sort of reminder service that could be configured to nag the
maintainers of a package in a situation like this? Personally, I would
appreciate it, and I think Fedora would benefit if we could do something to
minimize reverse-version skew between Fedora-latest and rawhide.
Hmmm. Would something like that:
http://autoqa.fedoraproject.org/results/247409-autotest/qa01.qa.fedoraproject.org/upgradepath/results/iwhd-1.2-1.fc16.html*
do the job for you? The associated explanations are quite clear:
https://fedoraproject.org/wiki/AutoQA_tests/Upgradepath
To play devil's advocate, the first time I received such an email from the
AutoQA bot, I did not fully understand what it meant...

Regards

Denis

*: simply found by looking within the package update page (
https://admin.fedoraproject.org/updates/FEDORA-2011-16933/iwhd-1.2-1.fc16),
and for which you should have received a mail with a few explanations
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120103/35513dca/attachment.html>
Jim Meyering
2012-01-03 21:33:05 UTC
Permalink
Post by Denis Arnaud
Hi Jim,
2012/1/3 <devel-request at lists.fedoraproject.org>
Is there some sort of reminder service that could be configured to nag the
maintainers of a package in a situation like this? Personally, I would
appreciate it, and I think Fedora would benefit if we could do something to
minimize reverse-version skew between Fedora-latest and rawhide.
Hmmm. Would something like that: http://autoqa.fedoraproject.org/results/
247409-autotest/qa01.qa.fedoraproject.org/upgradepath/results/
iwhd-1.2-1.fc16.html* do the job for you? The associated explanations are quite
Hi Denis,

That looks perfect.
Post by Denis Arnaud
clear: https://fedoraproject.org/wiki/AutoQA_tests/Upgradepath
To play devil's advocate, the first time I received such an email from the
AutoQA bot, I did not fully understand what it meant...
Regards
Denis
*: simply found by looking within the package update page (https://
admin.fedoraproject.org/updates/FEDORA-2011-16933/iwhd-1.2-1.fc16), and for
which you should have received a mail with a few explanations
Thanks for the pointers.

By running this command, I have signed up for iwhd-related
notifications in F-16 and rawhide:

ssh fedorapeople.org autoqa-optin iwhd devel F-16
Kamil Paral
2012-01-04 10:06:29 UTC
Permalink
Post by Jim Meyering
Thanks for the pointers.
By running this command, I have signed up for iwhd-related
ssh fedorapeople.org autoqa-optin iwhd devel F-16
With this command you will subscribe for rpmlint and rpmguard test results for every new build [1].

Depcheck and upgradepath test results should be posted as comments into Bodhi for all proposed updates, you don't need to do anything about that.

[1] http://jlaska.wordpress.com/2010/06/01/fedora-package-maintainers-want-test-results/
Brendan Jones
2012-01-05 00:48:12 UTC
Permalink
Post by Jakub Jelinek
Hi!
As part of preparations to switch GCC in F17 to GCC 4.7.0, I've performed
a test mass rebuild of rawhide (December 23th package list) using
gcc-4.7.0-0.1.fc17 on x86_64, and for those packages that failed also
rebuilt the same package with gcc-4.6.2-1.fc16 to quickly remove from the
list packages that fail for non-gcc related reasons.
What can packagers do now to minimize the number of FTBS later? I
noticed we have aa package in koji/rwhide that we can work with.

How should we proceed?
Tom Callaway
2012-01-05 21:06:48 UTC
Permalink
Fixed my broken packages in rawhide:

* libjingle - http://koji.fedoraproject.org/koji/taskinfo?taskID=3623092
* rekall - http://koji.fedoraproject.org/koji/taskinfo?taskID=3623152
* xbase - http://koji.fedoraproject.org/koji/taskinfo?taskID=3623229
* xsupplicant - http://koji.fedoraproject.org/koji/taskinfo?taskID=3623256

Thanks to Jakub for the very useful test and diagnosis.

~tom

==
Fedora Project

Continue reading on narkive:
Loading...