Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
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 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/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
On 2012-01-03 16:07, Jan Kratochvil wrote: 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 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
On Wed, Jan 04, 2012 at 10:22:21PM +0200, Ville Skyttä wrote: On 2012-01-03 16:07, Jan Kratochvil wrote: 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 pgpJMuWe6oE4z.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
Jan Kratochvil wrote: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
On 12/31/2011 12:56 PM, Jakub Jelinek 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. 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? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
On 01/02/2012 06:03 PM, Jim Meyering wrote: Nils Philippsen wrote: ... I've attached a list of packages and (co)maintainers, to easily find if one of your packages is affected or not. ... 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
On Mon, 02 Jan 2012 19:03:44 +0100, Jim Meyering wrote: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
2012/1/3 Pádraig Brady p...@draigbrady.com: On 01/02/2012 06:03 PM, Jim Meyering wrote: Nils Philippsen wrote: ... I've attached a list of packages and (co)maintainers, to easily find if one of your packages is affected or not. ... 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
Hi Jim, 2012/1/3 devel-requ...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
On Mon, Jan 02, 2012 at 07:03:44PM +0100, Jim Meyering wrote: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
Jakub Jelinek wrote: On Mon, Jan 02, 2012 at 07:03:44PM +0100, Jim Meyering wrote: 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 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. 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
Denis Arnaud wrote: Hi Jim, 2012/1/3 devel-requ...@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. 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
On Sat, 2011-12-31 at 12:56 +0100, Jakub Jelinek 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 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 n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 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:
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
On Jan 2, 2012, at 5:30 AM, Nils Philippsen wrote: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
On Mon, Jan 02, 2012 at 09:09:29AM -0700, Nathanael Noblet wrote: On Jan 2, 2012, at 5:30 AM, Nils Philippsen wrote: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
Nils Philippsen wrote: ... I've attached a list of packages and (co)maintainers, to easily find if one of your packages is affected or not. ... 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... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
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 'someclasssomearg' 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: 'templateclass 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=gccview=revrev=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
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
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 ja...@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 'someclasssomearg' 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: 'templateclass 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=gccview=revrev=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,
Re: Results of a test mass rebuild of rawhide/x86_64 with?gcc-4.7.0-0.1.fc17
On Sat, Dec 31, 2011 at 08:55:53AM -0600, Dennis Gilmore wrote: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with?gcc-4.7.0-0.1.fc17
On Sat, Dec 31, 2011 at 16:35:00 +0100, Jakub Jelinek ja...@redhat.com wrote: On Sat, Dec 31, 2011 at 08:55:53AM -0600, Dennis Gilmore wrote: 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
On 2011-12-31 13:56, Jakub Jelinek wrote: gcc-4.7.0-0.1.fc17 on x86_64 Is this package available somewhere? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
=?UTF-8?B?VmlsbGUgU2t5dHTDpA==?= ville.sky...@iki.fi writes: On 2011-12-31 13:56, Jakub Jelinek wrote: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with?gcc-4.7.0-0.1.fc17
On Sat, Dec 31, 2011 at 04:25:06PM +, Peter Robinson wrote: On Sat, Dec 31, 2011 at 3:35 PM, Jakub Jelinek ja...@redhat.com wrote: On Sat, Dec 31, 2011 at 08:55:53AM -0600, Dennis Gilmore wrote: 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 TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with?gcc-4.7.0-0.1.fc17
El Sat, 31 Dec 2011 16:35:00 +0100 Jakub Jelinek ja...@redhat.com escribió: On Sat, Dec 31, 2011 at 08:55:53AM -0600, Dennis Gilmore wrote: 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@download01 ~]$ ls /srv/pub/fedora/linux/development/rawhide/source/SRPMS/*fc11.src.rpm|wc -l 3 [ausil@download01 ~]$ ls /srv/pub/fedora/linux/development/rawhide/source/SRPMS/*fc12.src.rpm|wc -l 59 [ausil@download01 ~]$ ls /srv/pub/fedora/linux/development/rawhide/source/SRPMS/*fc13.src.rpm|wc -l 19 [ausil@download01 ~]$ ls /srv/pub/fedora/linux/development/rawhide/source/SRPMS/*fc14.src.rpm|wc -l 44 [ausil@download01 ~]$ ls /srv/pub/fedora/linux/development/rawhide/source/SRPMS/*fc15.src.rpm|wc -l 3334 [ausil@download01 ~]$ ls /srv/pub/fedora/linux/development/rawhide/source/SRPMS/*fc16.src.rpm|wc -l 3140 [ausil@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
