2017-05-20 20:22:51-!- K_F [~kristianf@gentoo/developer/k-f] has joined #gentoo-toolchain
2017-05-20 20:22:51-!- Irssi: #gentoo-toolchain: Total of 15 nicks [0 ops, 0 halfops, 0 voices, 15 normal]
2017-05-20 20:22:51-!- Irssi: Join to #gentoo-toolchain was synced in 0 secs
2017-05-20 20:25:51-!- Soap__ [~Soap__@gentoo/developer/soap] has joined #gentoo-toolchain
2017-05-20 20:59:46-!- mattst88 [~mattst88@gentoo/developer/mattst88] has joined #gentoo-toolchain
2017-05-20 21:02:25< dilfridge> hey there
2017-05-20 21:02:52< dilfridge> blueness: so tamiko asked me to organize this since he was kept up at the last moment
2017-05-20 21:03:34< slyfox> \o/
2017-05-20 21:03:56< dilfridge> so let's see if anyone of the team actually turns up, after all we've been exchanging mails on the alias for over a week now
2017-05-20 21:04:29< blueness> here
2017-05-20 21:05:36< dilfridge> the current member list is vapier (not here), blueness, dilfridge, kumba (not on irc), lu_zero (not here), mrueg (not here), dirtyepic (not on irc), tamiko, williamh (not here), zorry (not here)
2017-05-20 21:05:45< blueness> dilfridge: personally what i'd like is to be on toolchain and base-system and releng and on many arch teams so i can keep our stage3's well oiled and up to date
2017-05-20 21:06:00< dilfridge> sounds good to me
2017-05-20 21:06:31< dilfridge> I'm probably (in terms of toolchain) the least knowledgeable person around at the moment... willing to learn and invest time if needed though
2017-05-20 21:06:44< dilfridge> blueness: while we wait, 
2017-05-20 21:06:51< blueness> yes?
2017-05-20 21:07:05< dilfridge> I've had an idea a few minutes ago, let's see what you think of it
2017-05-20 21:07:22-!- kent\n [~kent@gentoo/developer/kentnl] has joined #gentoo-toolchain
2017-05-20 21:07:28< dilfridge> you remember that we postponed the "pie" flag to future (17.0) profiles
2017-05-20 21:07:41< dilfridge> so we're going to make new profiles anyway
2017-05-20 21:08:06< dilfridge> how about adding by default -std=c++14 there ?
2017-05-20 21:08:13< dilfridge> (or gnu14)
2017-05-20 21:08:31< dilfridge> the reason is the following
2017-05-20 21:08:41< blueness> dilfridge: we should not force c++14 but if we  have gcc-7 stable then it is the default
2017-05-20 21:08:41< dilfridge> there's a new ICU (59.1)
2017-05-20 21:09:08< dilfridge> and all reverse dependencies of ICU fail if they dont use at least c++11
2017-05-20 21:09:10< blueness> the choice of abi is an upstream choice which we should force
2017-05-20 21:09:16< [Arfrever]> Maybe stabilize GCC 6 and mask GCC 4 and 5 in new profiles?
2017-05-20 21:09:21< blueness> dilfridge: right
2017-05-20 21:09:28< blueness> err [Arfrever] right
2017-05-20 21:09:36< blueness> that's what i was going to suggest
2017-05-20 21:09:56< dilfridge> well, that's an alternative
2017-05-20 21:10:13< dilfridge> just that this blocks using the new ICU until gcc-6 is stable
2017-05-20 21:10:15< [Arfrever]> Or at least the part about masking of GCC 4 and 5 would allow to unmask ICU 59 in new profiles.
2017-05-20 21:10:29< dilfridge> (and there are a couple of sec bugs pending there)
2017-05-20 21:10:48< [Arfrever]> (And stabilization of ICU 59 would need stabilization of GCC 6.)
2017-05-20 21:11:57< dilfridge> right. the usual timeframe for stabilization of the new ICU, however, would be "call for stabilization in the security bug now".
2017-05-20 21:12:09< blueness> let me take a quick look at the git logs for icu
2017-05-20 21:12:39< [Arfrever]> Adition to -std=... flag to dozens of packages can be made faster due to e.g. need of faster stabilization of ICU 59.
2017-05-20 21:12:50< [Arfrever]> blueness: What git logs?
2017-05-20 21:13:04< dilfridge> I'm not so sure it's that critical, just stabilizing gcc-6 will probably take (much) longer.
2017-05-20 21:13:12< dilfridge> heh, icu uses subversion
2017-05-20 21:13:28< blueness> [Arfrever]: the logs on our tree, i just wanted to see who has been doing what to that package
2017-05-20 21:13:40 * dilfridge raises hand
2017-05-20 21:14:46< blueness> dilfridge: so on the gcc changelog there's usually an explanation of what versions of icu, isl etc that's required
2017-05-20 21:15:21< dilfridge> you mean required by gcc?
2017-05-20 21:15:27< blueness> yes
2017-05-20 21:15:36< dilfridge> that's not the problem
2017-05-20 21:16:07< blueness> current icu requires gcc-6 no?
2017-05-20 21:16:08< [Arfrever]> blueness: Maybe you should see https://bugs.gentoo.org/show_bug.cgi?id=icu-59
2017-05-20 21:16:12< [Arfrever]> blueness: No.
2017-05-20 21:16:12< dilfridge> no
2017-05-20 21:16:25< blueness> ah okay
2017-05-20 21:16:29< [Arfrever]> blueness: It just needs C++ >=2011, which happends to be default in GCC 6.
2017-05-20 21:16:39< [Arfrever]> (i.e. 2014 is default)
2017-05-20 21:16:40< dilfridge> the problem is that many packages in our tree fail with gcc-5 (current stable) or older and future icu
2017-05-20 21:17:08< dilfridge> because icu 59.1 needs these other packages to build with at least c++11
2017-05-20 21:17:23< blueness> got it so we need tree wide c++11
2017-05-20 21:17:26< blueness> or better
2017-05-20 21:17:36< K_F> dilfridge: is it really much different from bug 589412 ?
2017-05-20 21:17:38< willikins> K_F: https://bugs.gentoo.org/589412 "[TRACKER] Qt 5.7 requires C++11 support"; Gentoo Linux, Current packages; CONF; k_f:qt
2017-05-20 21:17:41< dilfridge> forcing c++11 is a downgrade for gcc-6, so not good
2017-05-20 21:18:00< dilfridge> prolly not
2017-05-20 21:18:10< blueness> dilfridge: just have icu depend on gcc-6 then
2017-05-20 21:18:11-!- taxidriver110 [~circuser-@p5DC562D4.dip0.t-ipconnect.de] has joined #gentoo-toolchain
2017-05-20 21:18:24< dilfridge> bug 618636
2017-05-20 21:18:26< willikins> dilfridge: https://bugs.gentoo.org/618636 "[TRACKER] Packages failing to build with ICU >=59"; Gentoo Linux, Current packages; CONF; arfrever.fta:office
2017-05-20 21:18:36< K_F> blueness: would require recompile of libs icu uses as well, so that likely won't be sufficient
2017-05-20 21:18:41< blueness> that'lls only be a problem if people have many versions of gcc installed and switch between them
2017-05-20 21:18:58< dilfridge> that's an option
2017-05-20 21:19:23< dilfridge> may I describe what I wanted to suggest? couple of lines...
2017-05-20 21:19:31< blueness> dilfridge: do it
2017-05-20 21:20:09< dilfridge> * new 17.0 profiles:
2017-05-20 21:20:09< dilfridge>    - add -std=c++14 to flags
2017-05-20 21:20:21< dilfridge>    - unmask new icu
2017-05-20 21:20:33< dilfridge>    - mask old gcc (<4.9.4)
2017-05-20 21:20:44< dilfridge> * current 13.0 profiles
2017-05-20 21:20:50< dilfridge>    - mas new icu
2017-05-20 21:20:59< dilfridge>    - mask new icu (and keep it masked)
2017-05-20 21:21:16< dilfridge> this means, 
2017-05-20 21:21:35< dilfridge> * nothing changes for current users (without manual intervention)
2017-05-20 21:22:04< dilfridge> * we do not have to add -std=c++11 or 14 to many packages just for a transition time
2017-05-20 21:22:07< blueness> dilfridge: the only concern i have is forcing c++14
2017-05-20 21:22:14< [Arfrever]> mgorny will probably mask GCC <4.9 everywhere anyway.
2017-05-20 21:22:32< dilfridge> * packages that do not build with c++14 need something in the ebuild like "append-cxxflags ..."
2017-05-20 21:22:59< dilfridge>    (but that's not for a transition time, but there to stay, because future compilers will always default to c++14 or newer)
2017-05-20 21:23:24< blueness> dilfridge: that's my concern, there may be a lot of them
2017-05-20 21:23:53< dilfridge> but we should already find them now in gcc-6 tinderbox runs
2017-05-20 21:24:02< dilfridge> (since gcc-6 defaults to c++14)
2017-05-20 21:24:14< [Arfrever]> dilfridge: In your plan, when do you plan to delete vulnerable ICU 58?
2017-05-20 21:24:22< dilfridge> as soon as possible
2017-05-20 21:24:43< slyfox> it means 13.0 profile deprecation
2017-05-20 21:24:47< dilfridge> yes
2017-05-20 21:25:34< blueness> dilfridge: if there are different versions of a package some of which build with c++14 and some (older versions) which don't, then we'll just have to mask those on provife 17.0
2017-05-20 21:25:51< dilfridge> yes... in the end, making an (unannounced, hidden) 17.0 test profile is cheap
2017-05-20 21:26:12< dilfridge> (with these changes, c++14 plus pie)
2017-05-20 21:26:24< blueness> dilfridge: i would recommending passing this by gentoo-dev@ and we'll work in that direction, it should work
2017-05-20 21:26:27< [Arfrever]> Adding 'append-cxxflags -std=c++14' to dozens of packages would be faster and easier.
2017-05-20 21:26:42< blueness> [Arfrever]: you think?
2017-05-20 21:27:18< [Arfrever]> Adding 'append-cxxflags -std=c++14' to selected packages does not exclude idea of new profiles which somehow force C++ 2014 for all packages.
2017-05-20 21:28:19< K_F> the requirement is only for c++11 isn't it?
2017-05-20 21:28:21< dilfridge> I agree that this is probably a faster workaround
2017-05-20 21:28:33< K_F> which is already being done for a lot of packages for Qt 5.7 support
2017-05-20 21:28:45< K_F> and ensures a proper upgrade path for security fixes without manual rebuild of world 
2017-05-20 21:28:56< dilfridge> K_F: yes, but forcing c++11 in a profile won't work (since the profile doesnt know if you're using gcc-6 ) 
2017-05-20 21:29:18< K_F> the append-cxxflags would likely be the lower requirement anyways
2017-05-20 21:29:24< dilfridge> yes
2017-05-20 21:29:35< dilfridge> so, how about this
2017-05-20 21:29:37< K_F> although if that is a requirement, it really should be made as such in the autoconf
2017-05-20 21:29:45< K_F> and upstreamed
2017-05-20 21:30:06< K_F> https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx_11.html
2017-05-20 21:30:29< [Arfrever]> dilfridge: Re "since the profile doesnt know if you're using gcc-6": profile.bashrc can know it.
2017-05-20 21:30:33< K_F> (as we're doing for the Qt 5.7 one)
2017-05-20 21:31:17< dilfridge> actually 
2017-05-20 21:31:21< dilfridge> I have a way more evil idea
2017-05-20 21:31:33< dilfridge> we hack the .pc files of the new ICU to add it
2017-05-20 21:31:44-!- taxidriver110 [~circuser-@p5DC562D4.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
2017-05-20 21:32:26< dilfridge> that's done on the icu-side only and should fix the entire problem nicely :)
2017-05-20 21:32:38-!- mrueg [~mrueg@gentoo/developer/mrueg] has joined #gentoo-toolchain
2017-05-20 21:32:40< [Arfrever]> dilfridge: Many packages do not use these .pc files.
2017-05-20 21:32:45< [Arfrever]> E.g. qtcore
2017-05-20 21:33:09< mrueg> meeting already started?
2017-05-20 21:33:24< [Arfrever]> Yes. 33 minutes ago.
2017-05-20 21:33:26< blueness> dilfridge: do all the packages depending on icu respect it?
2017-05-20 21:33:27< blueness> the .pc file i mean
2017-05-20 21:33:28< blueness> mrueg: yep, party's on!
2017-05-20 21:33:35< dilfridge> probably not
2017-05-20 21:33:38< K_F> mrueg: want me to provide a log to read backlog?
2017-05-20 21:33:48< mrueg> K_F: would be great
2017-05-20 21:34:00< dilfridge> anyway
2017-05-20 21:34:14< mrueg> I thought it's scheduled for Sunday but my memories betrayed me.
2017-05-20 21:34:41< dilfridge> blueness: [Arfrever]: my suggestion would be, to get ahead there fast, let's add flags in packages, but let's keep the idea of the profile and propose it on -dev
2017-05-20 21:34:50< K_F> mrueg: https://download.sumptuouscapital.com/gentoo/tmp/gentoo-toolchain.log.txt
2017-05-20 21:35:10< dilfridge> if something doesnt build with -std=c++14, it won't build with gcc-6 atm, so we should already see/know it
2017-05-20 21:35:19< dilfridge> so
2017-05-20 21:35:28< [Arfrever]> dilfridge, blueness: In my forked ebuilds of ICU in versions <59 I was changing icu-config and .pc files to print -std=... and I had to change some reverse dependencies to respect icu-config or .pc files.
2017-05-20 21:36:10< dilfridge> I suppose attendance won't get better, shall we have a loot at the agenda tamiko put together?
2017-05-20 21:36:24< dilfridge> https://archives.gentoo.org/gentoo-dev/message/588b60becec1699d3ed784c7ef3a8e83
2017-05-20 21:36:35 * dilfridge waves a short hello
2017-05-20 21:36:36< blueness> let's start
2017-05-20 21:36:41< mrueg> K_F: thanks!
2017-05-20 21:37:09< dilfridge> so first thing in the list is, CVEs
2017-05-20 21:37:24< dilfridge> blueness: could you maybe tell us how this was handled so far?
2017-05-20 21:37:32< blueness> dilfridge: in the past vapier has not been terribly concerned
2017-05-20 21:37:53< blueness> his position was toolchains are for building secure binaries, but don't have to be secure binaries themselves
2017-05-20 21:38:02< dilfridge> https://bugs.gentoo.org/buglist.cgi?email1=toolchain%40gentoo.org&email2=security%40gentoo.org&emailassigned_to2=1&emailcc1=1&emailtype1=substring&emailtype2=substring&list_id=3538408&query_format=advanced&resolution=---
2017-05-20 21:38:12< [Arfrever]> It depends on package and its part.
2017-05-20 21:38:19< blueness> so he's move quite slowly on problems in binutils, gcc etc
2017-05-20 21:38:30< [Arfrever]> CVEs for binutils and non-libstdc++ part of gcc are small problem.
2017-05-20 21:38:36< blueness> [Arfrever]: right
2017-05-20 21:38:56< [Arfrever]> CVEs for glibc and libstdc++ part of gcc affect everything.
2017-05-20 21:39:09< blueness> so i can take a look at those CVE and try movign things ahead
2017-05-20 21:39:25< mrueg> I guess there could be a similar solution like it was suggested for golang once if we want to enforce rebuilds?
2017-05-20 21:39:59< mrueg> virtual/compiler and virtual/libc, all packages depend on it via := and on security issues we raise the subslot on those virtuals
2017-05-20 21:40:52< [Arfrever]> mrueg: It does not make sense.
2017-05-20 21:41:13< slyfox> it would require portage or user to manually inject gcc/glibc dependencies into every ebuild
2017-05-20 21:41:24< dilfridge> so from the bug list I see a couple of things in binutils (which are probably not so critical)
2017-05-20 21:41:41< dilfridge> sane with old, masked gcc versions
2017-05-20 21:41:42< [Arfrever]> mrueg: Upgrade of shared libraries of glibc and gcc is sufficient. And users of static libraries are on their own...
2017-05-20 21:43:25< dilfridge> three CVEs in glibc which are fixed in our ~arch version
2017-05-20 21:43:30< dilfridge> one open sec bug for 2.25
2017-05-20 21:43:44< [Arfrever]> s/2.25/<2.26/
2017-05-20 21:44:42< dilfridge> the agenda says "stabilizing newer binutils and glibc" is urgent... any volunteers who want to look at this?
2017-05-20 21:46:39< blueness> me
2017-05-20 21:46:51< dilfridge> ++
2017-05-20 21:47:29< blueness> so what i can do is test on various arches and go from there
2017-05-20 21:47:38< dilfridge> I can go through the bugs and try to make sense of them. Let me know when I can help.
2017-05-20 21:47:46< blueness> i have lots of chroots where i can do a full system rebuild
2017-05-20 21:48:07< blueness> i'm going to start with binutils
2017-05-20 21:48:14< blueness> and then see about glibc
2017-05-20 21:48:39< slyfox> (beware of the broken unbootable kernels coming with toolchain update)
2017-05-20 21:49:00< blueness> slyfox: yeah i think alpha was hit with that
2017-05-20 21:49:29< dilfridge> bug 601014 	
2017-05-20 21:49:31< willikins> dilfridge: https://bugs.gentoo.org/601014 ">=sys-devel/gcc-4.9.4 generates broken kernel on ia64, leading to unbootable/uninstallable systems"; Gentoo Linux, Current packages; UNCO; emeric.maschino:toolchain
2017-05-20 21:49:41< [Arfrever]> blueness: About bug #617938, upstream bug https://sourceware.org/bugzilla/show_bug.cgi?id=21461 is still open.
2017-05-20 21:49:42< blueness> dilfridge: yep that's it ia64
2017-05-20 21:49:43< willikins> [Arfrever]: https://bugs.gentoo.org/617938 "sys-libs/glibc:  xdr_bytes and xdr_string functions buffer deserialization"; Gentoo Security, Vulnerabilities; IN_P; glsamaker:security
2017-05-20 21:49:44< slyfox> yes. that needs a tiny kernel patch
2017-05-20 21:49:45< K_F> can likely coordinate that with blackbird
2017-05-20 21:50:01< dilfridge> [Arfrever]: yeah I checked that one too
2017-05-20 21:50:46< dilfridge> ok moving on
2017-05-20 21:50:57< dilfridge> from the topic of sec bugs to gcc-porting
2017-05-20 21:51:12< dilfridge> https://bugs.gentoo.org/buglist.cgi?email1=toolchain%40gentoo.org&emailassigned_to1=1&emailtype1=substring&list_id=3538410&query_format=advanced&resolution=---&short_desc=gcc&short_desc_type=allwordssubstr
2017-05-20 21:51:20< dilfridge> right now 128 open bugs
2017-05-20 21:51:40< [Arfrever]> blueness: What do you think about forcing -fstack-protector-all in glibc >=2.25?
2017-05-20 21:52:06< blueness> [Arfrever]: should be okay
2017-05-20 21:52:11< dilfridge> however that number is in part so large because it's including all our "archived gcc versions"
2017-05-20 21:52:13< [Arfrever]> blueness: I have been using it for 3 months on non-hardened system without problems.
2017-05-20 21:53:26< blueness> [Arfrever]: i believe it
2017-05-20 21:53:27< blueness> [Arfrever]: amd64 right?
2017-05-20 21:53:57< [Arfrever]> blueness: Bug #609048 (I have local patch initially for glibc eblits, now for toolchain-glibc.eclass.)
2017-05-20 21:54:00< willikins> [Arfrever]: https://bugs.gentoo.org/609048 ">=sys-libs/glibc-2.25: Pass --enable-stack-protector=strong or --enable-stack-protector=all to configure"; Gentoo Linux, Current packages; CONF; arfrever.fta:toolchain
2017-05-20 21:54:18 * dilfridge goes get some food
2017-05-20 21:54:35< [Arfrever]> blueness: I use amd64.
2017-05-20 21:55:18< [Arfrever]> blueness: Read this bug. It has full description, so I will not re-paste it in IRC.
2017-05-20 21:56:14< blueness> i read it
2017-05-20 21:57:13< blueness> [Arfrever]: i'm okay with that, do you want to prepare a patch against toolchain-glibc.eclass and i'll test it out and push it
2017-05-20 21:57:16-!- toralf [~toralf@x4e36a129.dyn.telefonica.de] has joined #gentoo-toolchain
2017-05-20 21:57:31< blueness> but only for glibc >=2.25 of course
2017-05-20 21:58:14< [Arfrever]> blueness: The quality of patch is good as always for my patches. I have used 'if version_is_at_least 2.25 ; then'.
2017-05-20 21:58:28< blueness> good
2017-05-20 21:58:59< blueness> [Arfrever]: attach it to the bug
2017-05-20 22:02:01< blueness> i think the bigger problem righ tnow with gcc porting is that different versions of gcc won't build other versions
2017-05-20 22:02:24< dilfridge> ok
2017-05-20 22:02:45< dilfridge> could we document that somewhere? like, a table on a wiki page?
2017-05-20 22:03:04< dilfridge> the way I understand it you already have a lot of data there
2017-05-20 22:03:43< blueness> dilfridge: we should be able to compile two versions ahead and behind
2017-05-20 22:03:54< blueness> what would the table be for?  per arch?
2017-05-20 22:04:23< dilfridge> dunno 
2017-05-20 22:04:52-!- WilliamH [~william@gentoo/developer/williamh] has joined #gentoo-toolchain
2017-05-20 22:04:52< WilliamH> Hey folks, sorry, I was on a phone call and the time got away from me.
2017-05-20 22:04:52-!- WilliamH [~william@gentoo/developer/williamh] has left #gentoo-toolchain []
2017-05-20 22:04:54< blueness> i can take a look at those too
2017-05-20 22:04:55< dilfridge> I'm not 100% clear there what the "objective" should be
2017-05-20 22:05:33< dilfridge> right now this whole meeting sounds like "let's make work for blueness" and that's not what its intention was :]
2017-05-20 22:05:52< blueness> dilfridge: in the past, we've always tried to make sure that gcc-N can compile gcc-(N+1) and gcc-(N+2)
2017-05-20 22:07:44< tamiko> available now. :-/
2017-05-20 22:07:44< blueness> dilfridge: shall we move on to the multilibe issue?  there's not much to discuss on porting really
2017-05-20 22:07:48< blueness> hi tamiko 
2017-05-20 22:08:02-!- WilliamH [~william@gentoo/developer/williamh] has joined #gentoo-toolchain
2017-05-20 22:08:26< dilfridge> right, works for me
2017-05-20 22:08:40 * dilfridge back with the hot soup
2017-05-20 22:08:42< WilliamH> dilfridge: tamiko: Hey, sorry folks. Time got away from me. :(
2017-05-20 22:09:17< tamiko> All, please continue - I will try catching up with the backlog but will have to leave again in about 10 minutes. :-/
2017-05-20 22:09:20< blueness> dilfridge: so i'm not sure what the issue is with full multilib support
2017-05-20 22:09:26< dilfridge> so, what's the plan, toolchain-r1.eclass rewrite or precision fixes?
2017-05-20 22:09:32< dilfridge> tamiko knows best
2017-05-20 22:09:58< tamiko> The idea for the "toolchain" rewrite would be to make a mild cleanup of toolchain.eclass and revbump for newer versions.
2017-05-20 22:10:02< blueness> dilfridge: actually mgorny was thinking of writing the toolchain.eclass maybe we'll see what he wants to do
2017-05-20 22:10:35< dilfridge> the specific multilib issue was that boehm-gcc is a new dependency and multilib libraries are needed there afaik
2017-05-20 22:11:02< tamiko> Yes.
2017-05-20 22:11:02< dilfridge> but I think already in the present case there was some confusion about which gcc parts need what ABI of their deps
2017-05-20 22:11:38< tamiko> blueness: If that's the case I'll ping mgorny and ask him what he's up to.
2017-05-20 22:11:43< tamiko> blueness: No need to double the work.
2017-05-20 22:11:49< dilfridge> yes
2017-05-20 22:11:50< blueness> tamiko: right
2017-05-20 22:12:07< blueness> tamiko: this is going aback about one year
2017-05-20 22:12:16< dilfridge> he already had a working setup some time ago, where the only missing thing was gcj support
2017-05-20 22:12:17< tamiko> blueness: I'll talk to him.
2017-05-20 22:12:25< tamiko> I unfortunately have to leave now.
2017-05-20 22:12:28< dilfridge> now since gcj is going away anyway...
2017-05-20 22:12:52< dilfridge> cool
2017-05-20 22:13:22< dilfridge>  - How to tackle all open toolchain bugs? [3]
2017-05-20 22:13:22< dilfridge>    * Volunteers for individual packages? (e.g. binutils, glibc, etc.)
2017-05-20 22:13:26< blueness> my position was i wanted to keep the current  eclass, he wanted to dump the eclass and just go with individual ebuilds for each versions
2017-05-20 22:13:28< blueness> but now i think its time to move past that disagreement
2017-05-20 22:13:30< blueness> mgorny was just on a let's clean everything up spree, but it really wasn't necessary for toolchian
2017-05-20 22:13:30< dilfridge> ^ I think this is kinda redundant now
2017-05-20 22:13:54< blueness> dilfridge: we open up a tracker
2017-05-20 22:14:07< dilfridge> ok
2017-05-20 22:14:12< blueness> so first we add a new version of gcc, keyword masked
2017-05-20 22:14:17< dilfridge> right
2017-05-20 22:14:26< blueness> then we make sure we can build back and forth a few versions
2017-05-20 22:14:44< blueness> ie gcc-N can build gcc-(N+1) and N+2
2017-05-20 22:15:02< blueness> and make sure that the toolchain can rebuild itself
2017-05-20 22:15:23< blueness> then add ~arch for each arch where it works
2017-05-20 22:15:37< dilfridge> ok
2017-05-20 22:15:42< blueness> then open a tracker for packages breaking against the version of gcc to be tested
2017-05-20 22:16:01< blueness> when that gets down to just a few packages, you go ahead and stabilize
2017-05-20 22:16:03< dilfridge> if you dont mind I'll write that basic strategy (the way you're describing it now) up for the project page
2017-05-20 22:16:53< blueness> like this https://bugs.gentoo.org/show_bug.cgi?id=536984
2017-05-20 22:16:58< blueness> dilfridge: i can do that
2017-05-20 22:17:25< dilfridge> ok, if you want... just wanted to take off some of the load :]
2017-05-20 22:18:02< blueness> wierd there is no project toolchain
2017-05-20 22:18:11< dilfridge> https://wiki.gentoo.org/wiki/Project:Toolchain
2017-05-20 22:18:33< blueness> i don't see it on here https://wiki.gentoo.org/wiki/Category:Projects
2017-05-20 22:18:48< dilfridge> should be under base system
2017-05-20 22:18:54< blueness> ah yes
2017-05-20 22:19:19< blueness> wait i can't even see base system 
2017-05-20 22:19:40< dilfridge> err, this whole category page is weird
2017-05-20 22:19:56< blueness> yeah
2017-05-20 22:20:24< K_F> probably better to look at https://wiki.gentoo.org/wiki/Project:Gentoo
2017-05-20 22:21:05< K_F> or https://wiki.gentoo.org/wiki/Category:Gentoo_Projects
2017-05-20 22:21:16< blueness> okay anyhow i'll write up somehting on how to add a new version of gcc
2017-05-20 22:22:01< blueness> so there are two types of toolchain bugs
2017-05-20 22:23:27< blueness> 1) bugs in the toolchain code itself, eg in isl or gcc or glibc etc
2017-05-20 22:23:28< blueness> 2) the toolchain builds fine, but it can't compile older code
2017-05-20 22:23:30< blueness> eg c++ abi changes, but could be lots of other stuff too
2017-05-20 22:23:40< blueness> bugs of type 2 anyone can really tackle, and they're tracked by the tracker until everything gets cleaned up
2017-05-20 22:23:52< blueness> (i hope i've made the cycle clear)
2017-05-20 22:24:14< dilfridge> 2 is the "easy to check" part
2017-05-20 22:24:30< dilfridge> because you know that you're starting from a sane point
2017-05-20 22:24:38< blueness> yeah
2017-05-20 22:25:05< blueness> you don't really want to start 2 until 1 is taken care of, so you keyword mask
2017-05-20 22:25:06< dilfridge> btw, I never checked this, are the test phases functional/making sense?
2017-05-20 22:25:28< blueness> dilfridge: for glibc definitely
2017-05-20 22:25:59< blueness> but you have to be careful about what tests might fail, its a bit fragile
2017-05-20 22:26:00 * dilfridge just vaguely remembers some kitten rants
2017-05-20 22:26:16< dilfridge> yeah
2017-05-20 22:28:07< dilfridge> blueness: so which arches do you regularly test?
2017-05-20 22:28:25< blueness> amd64 arm mips ppc ppc64 x86
2017-05-20 22:28:40< blueness> mips is hard because there are so many variations
2017-05-20 22:28:41 * dilfridge winces
2017-05-20 22:28:46< blueness> so i'm a bit sloppy with mips
2017-05-20 22:28:53< blueness> and now ppc64el too
2017-05-20 22:28:55< dilfridge> our sparc machine is still dead
2017-05-20 22:29:06< blueness> i've given up on sparc sorry
2017-05-20 22:29:25< dilfridge> I dont mind :/
2017-05-20 22:29:53< blueness> okay should we move on to the other agenda items?
2017-05-20 22:29:53< dilfridge> mips, these are hardware variations? even more than arm?
2017-05-20 22:29:58< dilfridge> wfm
2017-05-20 22:30:04< dilfridge> there's not much left
2017-05-20 22:30:21< dilfridge> we already talked about the -std=c++14 / profiles thing
2017-05-20 22:30:30< dilfridge> last in the agenda was
2017-05-20 22:30:43< dilfridge> "quick (bi-)monthly meetings (~15 minutes) on IRC"?
2017-05-20 22:30:58< blueness> dilfridge: mips = big endian / little endian, abi = o32, n32, n64 (some other more exhotic), subarch = mips I, II, III, mips32r2, mips64r2
2017-05-20 22:31:10< dilfridge> :O
2017-05-20 22:31:19< K_F> dilfridge: its always fun to discuss "bi-" varieties, i.e twise a month or once every two months (I presume latter)
2017-05-20 22:31:38< dilfridge> I'd say every two weeks, but really short
2017-05-20 22:31:52< blueness> so i test little endian mips64 with o32, n32, n64 (lemote) and bit endian mips32r2 o32 (atheros router boards)
2017-05-20 22:31:52< WilliamH> dilfridge: ++
2017-05-20 22:32:05< blueness> every two weeks, but someone else organize them for me
2017-05-20 22:32:09< blueness> ;)
2017-05-20 22:32:12< K_F> dilfridge: my general recommendation is, for a global project, as much as possible should happen over email etc, to not require being there at specific time
2017-05-20 22:32:13< dilfridge> heh :)
2017-05-20 22:32:16< dilfridge> yes
2017-05-20 22:32:23< dilfridge> mail is good
2017-05-20 22:32:39< dilfridge> maybe even vapier or dirtyepic respond at some time ;)
2017-05-20 22:32:55< WilliamH> We really need to find a way to increase the bus factor for the toolchain stuff. ;-)
2017-05-20 22:33:01< dilfridge> ok shall we call it a day?
2017-05-20 22:33:11< slyfox> i have a PIE question :)
2017-05-20 22:33:13< dilfridge> I think I learned a lot, and if we document stuff...
2017-05-20 22:33:26< dilfridge> slyfox: shoot
2017-05-20 22:33:26< blueness> slyfox: shoot
2017-05-20 22:33:34< dilfridge> :)
2017-05-20 22:33:48< slyfox> once gcc-7.1 toolchain tries to push USE=pie by default. how about other "toolchains"?
2017-05-20 22:33:53< slyfox> for example clang
2017-05-20 22:33:53< blueness> physicist think alike 
2017-05-20 22:34:03< slyfox> will it be policy for all that generates binaries?
2017-05-20 22:34:06< blueness> slyfox: no idea with clang
2017-05-20 22:34:14< blueness> pie by default has been zorry's work
2017-05-20 22:34:23< slyfox> for example, i'll need to tweak dev-lang/ghc slightly to default to PIE
2017-05-20 22:34:29< slyfox> golang has similar knob
2017-05-20 22:35:44< WilliamH> slyfox: I need to see what that is for dev-lang/go?
2017-05-20 22:36:55< [Arfrever]> tamiko, blueness, dilfridge: Currently there are: toolchain.eclass toolchain-autoconf.eclass toolchain-binutils.eclass toolchain-glibc.eclass
2017-05-20 22:36:58< slyfox> WilliamH: it's a -pie flag
2017-05-20 22:36:58< [Arfrever]> tamiko, blueness, dilfridge: Since toolchain.eclass is only for gcc, a rewritten eclass for gcc could have better name toolchain-gcc.eclass instead of something ugly like toolchain-r1.eclass.
2017-05-20 22:37:19< dilfridge> mhh, or gcc.eclass
2017-05-20 22:37:33< WilliamH> yeah, gcc.eclass possibly.
2017-05-20 22:38:19< blueness> i prefer toolchain-gcc.eclass
2017-05-20 22:38:21< dilfridge> slyfox: I can imagine that it needs tweaking, I can't imagine that it's impossible... but we have clang experts so lets ask them
2017-05-20 22:39:15< blueness> okay i need to get some othe rstuff done, i think we're done here
2017-05-20 22:39:19< dilfridge> ++
2017-05-20 22:39:39< dilfridge> I'll send around mail for the next "15min meeting"
2017-05-20 22:39:46< dilfridge> cheers
2017-05-20 22:41:01< blueness> bah the lastest version of openrc breaks on uclibc
2017-05-20 22:41:05< blueness> must debug
2017-05-20 22:46:36-!- Introoter [uid189461@gateway/web/irccloud.com/x-rgbirpugojabfcah] has joined #gentoo-toolchain
2017-05-20 22:49:10< WilliamH> blueness: I need to know what breaks it on uclibc.
2017-05-20 22:49:18< WilliamH> blueness: s/it/openrc/
2017-05-20 22:50:10< WilliamH> blueness: I thought we were moving away from uclibc to musl?
2017-05-20 22:50:44< WilliamH> blueness: or did they finally decide to do an upstream release of uclibc?
2017-05-20 22:50:48< WilliamH> ;-)
2017-05-20 22:55:08-!- toralf [~toralf@x4e36a129.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
2017-05-20 22:58:01-!- toralf [~toralf@x4e36a129.dyn.telefonica.de] has joined #gentoo-toolchain
2017-05-20 23:07:01< blueness> WilliamH: i'm working on it
2017-05-20 23:07:02< blueness> and uclibc-ng is being well maintained upstream
2017-05-20 23:07:04< blueness> so we'll keep it
2017-05-20 23:08:17< WilliamH> blueness: keep both uclibc and uclibc-ng?
2017-05-20 23:08:31< blueness> WilliamH: no, just uclibc-ng
2017-05-20 23:08:37< blueness> both = uclibc-ng and musl
2017-05-20 23:08:53< WilliamH> blueness: ah ok.
2017-05-20 23:10:11< WilliamH> blueness: So is the bug with openrc/uclibc an openrc or uclibc issue? I try to stick to posix for OpenRC.
2017-05-20 23:11:20< blueness> WilliamH: no the problme is openrc/uclibc-ng and its something about the latest version, i'm working on blogs.gentoo.org right now, but i'll narrow it down to the commit
2017-05-20 23:11:20< WilliamH> blueness: The only code that is linux specific afaik is openrc-shutdown, openrc-init and kill_all in git.
2017-05-20 23:11:49< WilliamH> blueness: ah ok.
2017-05-20 23:13:34< WilliamH> blueness: One goal is for OpenRC to have its own init process on Linux so you don't need sysvinit. Whether or not Gentoo wants to switch to that is a separate discussion, but it will be an option farely soon.