[gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
On Fri, Jul 5, 2013 at 7:18 PM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: When we then move onto stage 2, it uses just the packages built during stage1 (/tmp/stage1root becomes /). This means, if seed stage has mpc.so.0.1 but portage has since included mpc.so.2 that the gcc in stage2 is linked against mpc.so.0.1 but only mpc.so.0.2 is installed. To combat this kind of failure we are currently running emerge --update - --deep --newuse --complete-graph --rebuild-if-new-ver gcc which could just be emerge --update gcc if eapi 5 subslots were used properly. The best solution to this is, and has always been, just updating gcc's deps during update_seed. Or am I misremembering something? As far as I know, you don't need to waste time rebuilding the seed stage's gcc, since gcc is rebuilt in stage2 and then everything is built by it in stage3.
Re: [gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
On Sat, 2013-07-06 at 00:08 -0700, Matt Turner wrote: On Fri, Jul 5, 2013 at 7:18 PM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: When we then move onto stage 2, it uses just the packages built during stage1 (/tmp/stage1root becomes /). This means, if seed stage has mpc.so.0.1 but portage has since included mpc.so.2 that the gcc in stage2 is linked against mpc.so.0.1 but only mpc.so.0.2 is installed. To combat this kind of failure we are currently running emerge --update - --deep --newuse --complete-graph --rebuild-if-new-ver gcc which could just be emerge --update gcc if eapi 5 subslots were used properly. The best solution to this is, and has always been, just updating gcc's deps during update_seed. Or am I misremembering something? As far as I know, you don't need to waste time rebuilding the seed stage's gcc, since gcc is rebuilt in stage2 and then everything is built by it in stage3. Yes, it does need to be rebuilt if key deps are updated. The gcc produced in the stage1 is broken, so won't run to rebuild itself during the stage2 run. Also the --rebuild-if-new-ver gcc only rebuilds gcc if it's deps are updated to new versions (likely breaking lib linkage), it is not unconditional. It is not as accurate as subslots, so may rebuild more often than possibly needed. But it is better than having unreliable stage builds, not knowing when they may break. -- Brian Dolbec dol...@gentoo.org
Re: [gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/06/2013 03:08 AM, Matt Turner wrote: On Fri, Jul 5, 2013 at 7:18 PM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: When we then move onto stage 2, it uses just the packages built during stage1 (/tmp/stage1root becomes /). This means, if seed stage has mpc.so.0.1 but portage has since included mpc.so.2 that the gcc in stage2 is linked against mpc.so.0.1 but only mpc.so.0.2 is installed. To combat this kind of failure we are currently running emerge --update - --deep --newuse --complete-graph --rebuild-if-new-ver gcc which could just be emerge --update gcc if eapi 5 subslots were used properly. The best solution to this is, and has always been, just updating gcc's deps during update_seed. Or am I misremembering something? You are misremembering that we are using preserve_libs to save our butts when mpc is updated and gcc is still linked to the old mpc. I feel very uncomfortable as the recommendation of preserve-libs is to remerge as soon as possible not build a whole system like this. Is there an actual failure here? Not that I've seen yet, but it's an awkward way to build in my opinion. - -Zero As far as I know, you don't need to waste time rebuilding the seed stage's gcc, since gcc is rebuilt in stage2 and then everything is built by it in stage3. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR2DeYAAoJEKXdFCfdEflKDwwP/1Pr2eB9GjSKncEabiB9WkEb eziSaccKcsmjdXq9Svg0dfTM9m9rgroK0iM15IWLHhbAoU/5beVPv4bOYVYejYkP NBMWp2+MoIE7VRhziFToj7tHxTnXsUg1l3dMFWECewWpMewo9lZw1eYTn/iaUGaI tkfNi7iQV9PvfknUgtQZ8lfgSUjUz2CdtjCyjaoMpO+vls+gVvH74vGETIMMrHWr CN7iMfx7F6FGpc1+FxZ0CJ1zKSifY/1R+dLABass8xaLRMPNqTIpm8b37xD2tHOA f2pfzCIgkwLEo8moJrmkl21CqC2CjqZ0HPqd3dd/wSTg2x1ccslNHVOUf8+mZu1I 4zwJUwS7e2w8rxcq/UTu9x3J18D2doFjLg1mLUtWgmptn9Tydr/GYL+yYJei0yK+ MiADpdK+UI5frUo1B8bZ+Gs0N5IIh2pcGkjdupz4HXRAeD+2VN5G0HBpTZ8I4vNI rK9wRQN1iyxb4sn0Wr0n+GwSlxyTao6yuUSJwT5nfD1k9gSGI9Zh7tERlD/D9ceN Vfvv0No+ikh47TDjm3hSmz2fdbTT5vxKecnXT72EpYQwIZFoVMo7tnRVwxd4gBbM Fx4LDUaSn3ommMBZF/jRt5zsn+cGMB/7qHkNo1DPIbKgXgExEQWRz7Lxhy8Hm4er YYVhPl4Zhc0/BCBwBpK/ =zakW -END PGP SIGNATURE-
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On Thu, 20 Jun 2013 10:39:54 +0200 Fabio Erculiani lx...@gentoo.org wrote: The final outcome I would love to see is that everybody eventually graduates from kindergarten :-) And perhaps introduce a culture-fit score in the recruiting, mentoring process. Maybe we should require everyone to be able to recite /usr/share/fortune/gentoo-dev[1]. It's a start, right? jer [1] USE=offensive emerge games-misc/fortune-mod-gentoo-dev but let's not put this particularly useful hint in the quizzes. ;-)
Re: [gentoo-dev] Patches on bug reports: thanks but no thanks for the credit
On Thu, 04 Jul 2013 09:31:35 -0700 Brian Dolbec dol...@gentoo.org wrote: Thank you for the extra effort. I appreciate it, although for the one I had recently, it made it harder. I had just migrated the ebuild to the new python eclasses. So the diff included the reversal of those changes too. That happened during morning coffee. An honest mistake. jer
Re: [gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
On Sat, Jul 6, 2013 at 12:46 AM, Brian Dolbec dol...@gentoo.org wrote: Yes, it does need to be rebuilt if key deps are updated. The gcc produced in the stage1 is broken, so won't run to rebuild itself during the stage2 run. But we keep the old libs around via preserve_libs, and once stage1 is done we effectively throw the seed stage out.
Re: [gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
On Sat, Jul 6, 2013 at 8:28 AM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: You are misremembering that we are using preserve_libs to save our butts when mpc is updated and gcc is still linked to the old mpc. I feel very uncomfortable as the recommendation of preserve-libs is to remerge as soon as possible not build a whole system like this. Is there an actual failure here? Not that I've seen yet, but it's an awkward way to build in my opinion. Keeping the old libs seems perfectly fine, since it's in a seed stage that we don't care about after stage1 is complete. An unnecessary build of gcc may not matter much on a relatively fast amd64, but it's going to be a pain on a bunch of slower architectures. And on mips/multilib it'll be even worse since we get to build the libraries for three ABIs.
Re: [gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
On Sat, 2013-07-06 at 09:36 -0700, Matt Turner wrote: On Sat, Jul 6, 2013 at 12:46 AM, Brian Dolbec dol...@gentoo.org wrote: Yes, it does need to be rebuilt if key deps are updated. The gcc produced in the stage1 is broken, so won't run to rebuild itself during the stage2 run. But we keep the old libs around via preserve_libs, and once stage1 is done we effectively throw the seed stage out. It could be that I missed that combination of changes that could occur during my testing. But I am quite sure that it failed for me. You could always do some re-runs of those tests using an older seed stage built against libmpc.so.1.
Re: [gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
On 07/06/2013 12:39 PM, Matt Turner wrote: On Sat, Jul 6, 2013 at 8:28 AM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: You are misremembering that we are using preserve_libs to save our butts when mpc is updated and gcc is still linked to the old mpc. I feel very uncomfortable as the recommendation of preserve-libs is to remerge as soon as possible not build a whole system like this. Is there an actual failure here? Not that I've seen yet, but it's an awkward way to build in my opinion. Keeping the old libs seems perfectly fine, since it's in a seed stage that we don't care about after stage1 is complete. An unnecessary build of gcc may not matter much on a relatively fast amd64, but it's going to be a pain on a bunch of slower architectures. And on mips/multilib it'll be even worse since we get to build the libraries for three ABIs. Thanks Matt, I was going to make that point. ~3 days to recompile world on the lemote yeelong. -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197
