Log for 20160612 meeting.

1 files changed, 335 insertions, 0 deletions

diff --git a/meeting-logs/20160612.txt b/meeting-logs/20160612.txt
new file mode 100644
index 0000000..0cd61b8
--- /dev/null
+++ b/meeting-logs/20160612.txt
@@ -0,0 +1,335 @@
+2016-06-12 21:01:15<@blueness> yep its time
+2016-06-12 21:01:24<@blueness> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
+2016-06-12 21:01:30<@blueness> begin meeting
+2016-06-12 21:01:49<@blueness> agenda: https://archives.gentoo.org/gentoo-project/message/50dbe189dd2641d5730f08944e7fa7ce
+2016-06-12 21:02:05<@blueness> 1. roll call: dilfridge, ulm, jlec, K_F, WilliamH, rich0
+2016-06-12 21:02:07 * ulm here
+2016-06-12 21:02:08 * rich0 here
+2016-06-12 21:02:09 * K_F here
+2016-06-12 21:02:10 * dilfridge here
+2016-06-12 21:02:13 * WilliamH here
+2016-06-12 21:02:23<@blueness> jlec?
+2016-06-12 21:02:26 * Soap___ here
+2016-06-12 21:02:31< Soap___> I'm proxying for him
+2016-06-12 21:02:35<@blueness> ah okay
+2016-06-12 21:02:43<@blueness> let me make a note
+2016-06-12 21:02:54< Soap___> he told me he mailed it around
+2016-06-12 21:03:17<@K_F> he mentioned it on IRC at least
+2016-06-12 21:03:20<@blueness> i’ll take your word for it, since the punishment for lying is crucifixion
+2016-06-12 21:03:27<@K_F> 2016-06-09 22:51:01< jlec> soap will proxy me on sunday.
+2016-06-12 21:03:40<@blueness> okay we’re all here
+2016-06-12 21:04:08<@blueness> 2. Discussion on mgorny’s items  - https://archives.gentoo.org/gentoo-dev/message/68a870c0519fb1cb7152db38fc9d4935
+2016-06-12 21:04:30<@blueness> so in case you’re not aware, mgorny withdrew all his items
+2016-06-12 21:04:47<@blueness> i asked him in irc if he was serious or this was just drama and he said he’s serious
+2016-06-12 21:05:01<@dilfridge> how serious!
+2016-06-12 21:05:06<@blueness> yeah right
+2016-06-12 21:05:24<@WilliamH> He tends to do this when someone challenges him.
+2016-06-12 21:05:31<@blueness> i think we should look through the list and see if we want to discuss any of these points despite his withdrawal
+2016-06-12 21:05:40<@ulm> I'd like us to discuss item 2d
+2016-06-12 21:06:01<@K_F> well, from a point of procedure we can add our own cases without necessarily having it proposed from another dev, so if anyone is interested in discussing any of the points it can be of interest still
+2016-06-12 21:06:25<@blueness> ulm: i am ready to discuss 2c and 2d only
+2016-06-12 21:06:44<@blueness> without mgorny to elaborate, i can’t make sense of the others
+2016-06-12 21:06:50< Soap___> whats the problem with USE=multislot? the weird orphanage?
+2016-06-12 21:06:53<@dilfridge> I'd like to discuss 2c
+2016-06-12 21:06:56<@ulm> blueness: 2d is what I said :)
+2016-06-12 21:07:07<@blueness> ulm: i know i’m agreeing with you
+2016-06-12 21:07:17<@WilliamH> Soap___: the dynamic setting of SLOT= breaks metadata
+2016-06-12 21:07:31< Soap___> WilliamH: but dynamic SLOT is gone anyways?
+2016-06-12 21:07:32<@dilfridge> WilliamH: that's gone... different problem now
+2016-06-12 21:07:40<@WilliamH> dilfridge: ah ok.
+2016-06-12 21:07:45<@ulm> 2b is sort of moot once 2d will be implemented
+2016-06-12 21:08:10< mgorny> i am around if somebody needs me (esp. after being highlighted for the third time ;-p)
+2016-06-12 21:08:15<@K_F> 2e is still actively debated, too early for council involvement imho
+2016-06-12 21:08:16<@blueness> okay let’s discuss 2c and 2d only and defer the others.  i can start with 2c, it shoudl be quick
+2016-06-12 21:08:41< Soap___> ok, start with 2c
+2016-06-12 21:09:01<@ulm> +1
+2016-06-12 21:09:21<@WilliamH> Elaborate a bit on 2C, what's the deal?
+2016-06-12 21:09:39<@blueness> any other comments before we start with 2c?
+2016-06-12 21:09:40<@blueness> okay a bit of history since i’m in the toolchain gang
+2016-06-12 21:09:41<@blueness> use mutlislot was being called in the global scope
+2016-06-12 21:09:41<@blueness> this was breaking metadata generation
+2016-06-12 21:09:47<@dilfridge> so, basically, after removing the previous multislot abuse...
+2016-06-12 21:09:59<@blueness> so vapier moved it out of the globl scope but then he put in these blockers
+2016-06-12 21:10:10< Soap___> how do the blockers look like?
+2016-06-12 21:10:13<@dilfridge> (and didnt explain to anyone why)
+2016-06-12 21:10:36<@K_F> Soap___: !multislot? ( !<${CATEGORY}/gcc-4.9 )
+2016-06-12 21:10:38<@blueness> now, if a users has USE=mutlislot SLOT=4.9.3 blocks against SLOT=4.9 and you can’t update gcc-4.9.3
+2016-06-12 21:10:51<@blueness> K_F: ^^^ thank yoiu that’s it
+2016-06-12 21:11:11< Soap___> i.e., force unload all old x.y SLOTs?
+2016-06-12 21:11:11<@blueness> so, the blocker goes away if we force USE=multislot for everyone
+2016-06-12 21:11:12<@ulm> blueness: should be USE="-multislot" I guess?
+2016-06-12 21:11:16<@K_F> earlier version was a bit strange, that had package version for each revbump, now it blocks earlier than 4.9 consistently
+2016-06-12 21:11:26<@K_F> s/revbump/version bump/
+2016-06-12 21:11:28<@blueness> 1 sec guys, let me explain the pros and cons
+2016-06-12 21:11:51<@blueness> if you force USE=multislot for everyone, then everyone gets mutliple versions of gcc which iwll accumulate on bumps
+2016-06-12 21:12:06<@dilfridge> (as in earlier times)
+2016-06-12 21:12:21<@blueness> but if you turn off USE=multislot for everyone, then we have abi breakage in c++ on gcc version bumps withoiut rebuilding all c++ libraries
+2016-06-12 21:12:41<@blueness> the lesser of two evils is forcing USE=multislot for everyone
+2016-06-12 21:12:48< Soap___> blueness: ... we have that anyways?
+2016-06-12 21:13:09<@blueness> Soap___: yes and it will hit hard between 4.9 and 5.3
+2016-06-12 21:13:11<@ulm> IMHO this is an abuse of blockers, which are intended for packages that cannot be installed at the same time
+2016-06-12 21:13:12<@dilfridge> did anyone ever explain or find out why the blocker exists now?
+2016-06-12 21:13:14<@K_F> blueness: does it actually still work even with multislot in that case? since it isn't properly SOnamed upstream
+2016-06-12 21:13:15<@ulm> but these gcc versions can be installed in parallel
+2016-06-12 21:13:28<@blueness> ulm:  i agree
+2016-06-12 21:13:34< Soap___> blueness: but question
+2016-06-12 21:13:38<@blueness> yes?
+2016-06-12 21:13:44< Soap___> why does the main tree have multislot anyways?
+2016-06-12 21:13:51< xiaomiao> and it introduces new problem: now you will be forced to manually clean up after installing gcc, which is very bad
+2016-06-12 21:13:56<@ulm> in addition it's an abuse of use flags, because installed files don't change
+2016-06-12 21:14:03< Soap___> dare I say, 99% of [gentoo] gcc users dont need multislotted GCCs
+2016-06-12 21:14:13< xiaomiao> Soap___: "need" ?
+2016-06-12 21:14:20<@blueness> Soap___: the default is supposed to be one gcc only per version
+2016-06-12 21:14:26< Soap___> blueness: exactly
+2016-06-12 21:14:29<@blueness> eg only one 4.8 only one 4.9 etc
+2016-06-12 21:14:31<@dilfridge> it was kinda nice to have gcc:4.8 and gcc:4.9 together
+2016-06-12 21:14:33< Soap___> which is gone with USE=multislot
+2016-06-12 21:14:45<@blueness> USE=multislot allows 4.9.2 4.9.3 etc
+2016-06-12 21:14:54< Soap___> it just accumulates
+2016-06-12 21:14:57<@blueness> yeah
+2016-06-12 21:15:07<@blueness> but as ulm said, the can all be installed at once
+2016-06-12 21:15:23< Soap___> cant all of this multislot commotion get shifted into the toolchain overlay?
+2016-06-12 21:15:23<@blueness> again the lesser of two evils is to force USE=multislot
+2016-06-12 21:15:30< Soap___> agreed
+2016-06-12 21:15:37<@dilfridge> what I dont understand is,
+2016-06-12 21:15:39< Soap___> but its imo still far from an optimal solution
+2016-06-12 21:15:59<@blueness> Soap___: USE=multislot was supposed to be for toolchain ninjas only
+2016-06-12 21:16:11<@blueness> so having USE=multislot in the tree and on an overlay is overkill
+2016-06-12 21:16:13< Soap___> blueness: yes, and now its being shoved down everyone's throats
+2016-06-12 21:16:18<@dilfridge> nearly everyone agreed that the old behaviour without multislot (e.g. SLOT=4.8)  was the sane and useful variant
+2016-06-12 21:16:28< Soap___> dilfridge: absolutely
+2016-06-12 21:16:54<@dilfridge> so has anyone ever heard any sort of justification why 1) first it was switched to 4.8.x for everyone, and 2) then the blockers were introduced?
+2016-06-12 21:17:04< Soap___> blueness: what I'm saying, cant we stick all the multislot stuff in the overlay, and live without USE=multislot in the main tree?
+2016-06-12 21:17:07<@dilfridge> I mean, like, technical reasons????
+2016-06-12 21:17:38<@blueness> i’m not sure what would happen with cross compilers
+2016-06-12 21:17:46<@blueness> and i’m not sure what would happend with binutils
+2016-06-12 21:18:17<@blueness> so how about i email vapier and suggest:
+2016-06-12 21:18:30<@ulm> but emerge --depclean will purge the old versions?
+2016-06-12 21:19:35<@K_F> ulm: unless I'm mistaken that might cause issues with libstdc++ linking and ABI not being consistent or properly versioned
+2016-06-12 21:19:39<@blueness> 1) USE=-multislot in the tree and remove all blockers
+2016-06-12 21:19:41<@blueness> 2) move USE=multislot to the overlay
+2016-06-12 21:19:42<@blueness> ulm: it will, and i’m afraid of what that might do to libraries linking aginas the old libstdc++.so
+2016-06-12 21:19:42<@blueness> i sent out a news item about it, and so did vapier
+2016-06-12 21:19:52<@blueness> correct, that’s why its safer to do USE=multislot
+2016-06-12 21:20:22< Soap___> blueness: but, libstdc++.so.6 is always from the newest GCC right?
+2016-06-12 21:20:36< Soap___> so if you compile with 4.7, it gets linked to the 4.9 libstdc++.so.6
+2016-06-12 21:20:51<@K_F> Soap___: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758
+2016-06-12 21:20:52<@blueness> Soap___: its not that easy
+2016-06-12 21:21:13<@blueness> i hate to pull a flameeyes on you but read my blog post afterwards https://blogs.gentoo.org/blueness/2015/03/10/the-c11-abi-incompatibility-problem-in-gentoo/
+2016-06-12 21:21:18<@K_F> Soap___: and downstream we have https://bugs.gentoo.org/show_bug.cgi?id=542482
+2016-06-12 21:21:38<@K_F> blueness: heh, thats the easier choice indeed :)
+2016-06-12 21:21:42< Soap___> blueness: I get all that
+2016-06-12 21:21:46<@K_F> its well written so worth the read
+2016-06-12 21:21:48< Soap___> but GCC < 5.1 is a lsot cause anyway
+2016-06-12 21:21:51<@blueness> K_F: yeah my blog post basically summarizes those two bugs
+2016-06-12 21:22:20<@WilliamH> So are we just concerned about the reason for the blockers?
+2016-06-12 21:22:20< Soap___> once you're in a GCC 5.1+ world, there's no going back, independent of multislot
+2016-06-12 21:22:42<@K_F> Soap___: which is actually something that the current blocker will set up for
+2016-06-12 21:22:53<@blueness> correct
+2016-06-12 21:22:54<@K_F> at that point you'll have a blocker for earlier than <5.1 and do a full rebuild of c++ files
+2016-06-12 21:23:07< Soap___> K_F: ok, but we can have those blockers independently of multislot
+2016-06-12 21:23:08<@K_F> which might be a technical reason for having it in place
+2016-06-12 21:23:16<@dilfridge> ok
+2016-06-12 21:23:17< Soap___> not?
+2016-06-12 21:24:02<@WilliamH> It sounds like the easier choice is to keep gcc multislotted in the tree.
+2016-06-12 21:24:05<@blueness> okay rather than protract a discussion that we probably can’t solve here, let me email vapier and bring xiaomiao’s bug to his attention
+2016-06-12 21:24:21<@ulm> blueness: +1
+2016-06-12 21:24:30<@blueness> i’ll ask if he wants to force USE=multislot universally
+2016-06-12 21:24:32<@K_F> it would be nice to get a description of the issues it intends to solve
+2016-06-12 21:24:33<@dilfridge> blueness++ (but will that help?)
+2016-06-12 21:24:45<@ulm> we also have QA bug 584610
+2016-06-12 21:24:47< willikins> ulm: https://bugs.gentoo.org/584610 "[QA] sys-devel/gcc[-multislot] blockers and upgrade behavior change"; Gentoo Linux, Unspecified; CONF; mgorny:qa
+2016-06-12 21:24:58<@blueness> dilfridge: i don’t know vapier answers me but he’s super busy
+2016-06-12 21:24:59<@ulm> so QA will act on it at some point
+2016-06-12 21:25:07<@K_F> blueness: but will the multislot part solve the issues we're talking about? doesn't it potentially fail when switching active compiler as it links to latest one anyways?
+2016-06-12 21:25:36<@blueness> K_F: it will solve the blocker issue, but it will not solve the abi mismatch issue
+2016-06-12 21:25:41<@dilfridge> so what happens if gcc-5 is installed, but not activated?
+2016-06-12 21:26:12<@blueness> dilfridge: if you have c++ libraries which link against the old 4.9 libstdc++.so you’ll get breakage
+2016-06-12 21:26:14<@K_F> blueness: but the blocking issue might actually be related to having a full upgrade past a point of no return?
+2016-06-12 21:26:33<@blueness> K_F: that’s part of it
+2016-06-12 21:26:45<@dilfridge> since old gcc-4 will try to work with new libstdc++ ?
+2016-06-12 21:26:47<@K_F> that would be removed if we force multislot atm
+2016-06-12 21:26:47<@blueness> but he should have put it in gcc-5* only
+2016-06-12 21:26:57<@K_F> dilfridge: yes, and fail due to symbol mismatch
+2016-06-12 21:27:08<@dilfridge> ok this is painful
+2016-06-12 21:27:11<@K_F> dilfridge: or should say, applications compiled with gcc-4
+2016-06-12 21:27:28<@blueness> dilfridge: because the libstdc++.so that’s used at link time and the one that’s used at load time are mismatched
+2016-06-12 21:27:38<@K_F> blueness: testing out a bit how it works with earlier versions etc etc, can be prudent in any case
+2016-06-12 21:27:46<@dilfridge> that sounds like a deeper design problem in gentoo
+2016-06-12 21:27:59<@K_F> I'm not following gcc close enough to know just how often such breaks happen and how well announced they are
+2016-06-12 21:28:09< Soap___> dilfridge: more like the way ld works on unix-liek systems
+2016-06-12 21:28:09<@blueness> dilfridge: its a gentoo design + gcc design problem, there’s enough blame to go around
+2016-06-12 21:28:20<@K_F> dilfridge: it is
+2016-06-12 21:28:21< Soap___> K_F: it shouldnt happen again soon
+2016-06-12 21:28:34< Soap___> the C++11 ABI is stable now
+2016-06-12 21:29:19<@K_F> Soap___: and then the issue comes back with C++14 again..
+2016-06-12 21:29:24< Soap___> K_F: no
+2016-06-12 21:29:33< Soap___> C++14 is already default
+2016-06-12 21:29:39<@blueness> the gcc issue is that it doesn’t add an soname to libstdc++.so
+2016-06-12 21:29:40<@blueness> Soap___: it is as of gcc5 and it is also the default
+2016-06-12 21:29:41<@blueness> okay i think i’d like to draw this to a close, again i don’t think we’ll fix anything here
+2016-06-12 21:29:43<@K_F> Soap___: make that 17 :)
+2016-06-12 21:29:44< Soap___> and by the looks of it, C++17 isnt mandating anything that changes the ABI
+2016-06-12 21:29:56<@blueness> yeah c++14 and c++17 are coming down the pipeline
+2016-06-12 21:30:10< Soap___> blueness: so you email vapier?
+2016-06-12 21:30:37< Soap___> I still think getting rid of USE=multislot would be the globally optimal solution
+2016-06-12 21:30:45<@blueness> yes, so if there are no more comments that add further concerns, i’ll email vapier about the bad blockage problem and see what he thinks
+2016-06-12 21:31:06<@blueness> i’ll repeat ulm’s point about this being an abuse of blockers
+2016-06-12 21:31:08<@K_F> I'd prefer if that email is formulated as a request for description of the behavior
+2016-06-12 21:31:09<@WilliamH> Soap___: you mean enabling it universally and dropping the use flag?
+2016-06-12 21:31:13<@K_F> not as "abuse of blockers"
+2016-06-12 21:31:24<@K_F> because it might very well have technical merit related to abi breakage
+2016-06-12 21:31:26< Soap___> WilliamH: no, I want SLOT=4.9 back and not SLOT=4.9.3
+2016-06-12 21:32:02<@WilliamH> Soap___: I think blueness explained why the other way is better... abi issues etc.
+2016-06-12 21:32:21<@blueness> okay let’s move on to 2d
+2016-06-12 21:32:31<@blueness> 2d. renaming LÍNGUAS to I18N or L18N
+2016-06-12 21:32:46<@blueness> ulm: this is of interest to you, do you want to say a few words
+2016-06-12 21:33:02<@ulm> it's more a replacement than a renaming
+2016-06-12 21:33:13<@blueness> oh?
+2016-06-12 21:33:35<@ulm> basically, LINGUAS would stop to be a USE_EXPAND and become a normal env variable
+2016-06-12 21:34:02<@ulm> and L10N would be used to control e.g. installation of language bundles
+2016-06-12 21:34:03<@blueness> well its used by gettext so its a clash
+2016-06-12 21:34:40<@ulm> it's all explained in detail in the various ML posts
+2016-06-12 21:35:14< Soap___> ulm: can you fill us in on the roadmap? how will languages then be handled? install_mask?
+2016-06-12 21:35:18<@ulm> the two linked in mgorny's post
+2016-06-12 21:35:25<@ulm> https://archives.gentoo.org/gentoo-dev/message/a08ea09c2c8e534fd9bc1146703c66ff
+2016-06-12 21:36:14<@ulm> Soap___: ebuilds can generate LINGUAS from L10N
+2016-06-12 21:36:16<@blueness> https://archives.gentoo.org/gentoo-dev/message/a08ea09c2c8e534fd9bc1146703c66ff
+2016-06-12 21:36:17<@K_F> ulm: if we do this, should it be done in new EAPI or retroactively?
+2016-06-12 21:36:23<@blueness> lol beat me ulm
+2016-06-12 21:36:55<@ulm> K_F: I don't see why this would be EAPI related
+2016-06-12 21:37:09<@ulm> it's removal of one USE_EXPAND and addition of another
+2016-06-12 21:37:16< Soap___> ulm: so I understand there's two approaches? install_mask and generating the right linguas?
+2016-06-12 21:37:53<@dilfridge> install_mask is only a related hack, but not precisely necessary here
+2016-06-12 21:37:59<@K_F> ulm: so we potentially get a broad user-impact as a result of it
+2016-06-12 21:38:01<@ulm> also users can still set LINGUAS as and env var IIUC
+2016-06-12 21:38:11<@ulm> s/and/an/
+2016-06-12 21:38:16< Soap___> but its discouraged?
+2016-06-12 21:38:36<@dilfridge> afaik the main problem is that the semantics of gettext LINGUAS and a use-expand do not agree
+2016-06-12 21:38:43<@ulm> dilfridge: I agree that we should not rely on INSTALL_MASK
+2016-06-12 21:39:00<@K_F> dilfridge: indeed, otherwise we could just pass it through as env var to begin with
+2016-06-12 21:39:29 * WilliamH wishes we would quit abusing INSTALL_M
+2016-06-12 21:39:38<@WilliamH> aINSTALL_MASK
+2016-06-12 21:39:42<@ulm> one problem is that in EAPI 5 LINGUAS will be reduced to the flags that are in IUSE
+2016-06-12 21:39:53<@ulm> and not all ebuilds handle this properly
+2016-06-12 21:40:26<@ulm> plus there is a related portage bug (which was mgorny's item 2b)
+2016-06-12 21:40:31<@dilfridge> so an EAPI bump leads to dropping localizations if not done really carefully
+2016-06-12 21:40:34<@K_F> so before any switch a tracker should be created identifying ebuilds that might have an issue
+2016-06-12 21:40:42<@blueness> ulm: does QA have a plan for how to fix both LINGUAS issues?
+2016-06-12 21:41:15<@ulm> there's a portage bug open, and IIRC there's a patch already
+2016-06-12 21:41:21<@blueness> i would thinkg the first issue LINGUAS-gettext can be solved by unsetting the variable in the portage before you even hit the ebuild, no?
+2016-06-12 21:41:53<@ulm> not if it's a USE_EXPAND
+2016-06-12 21:41:54<@blueness> ulm: can the portage people just merge that in, or do you need action from the body of devs?
+2016-06-12 21:42:18<@ulm> I think the latest plan was to wait for L10N
+2016-06-12 21:42:28<@ulm> and when that is done, fix portage
+2016-06-12 21:42:58<@dilfridge> ok so why not do that?
+2016-06-12 21:43:05<@blueness> so i don’t see much action for the Council now, its good that we know about it, but i don’t think we need to make any decisions
+2016-06-12 21:43:09<@K_F> as long as we can minimize the impact on users, announce it properly, and do a job cleaning up the tree first..
+2016-06-12 21:43:14<@K_F> but yeah, not much for council to do here atm
+2016-06-12 21:43:31<@ulm> there was a news item draft by leio already
+2016-06-12 21:43:49<@blueness> ulm: i did see that float aroudn the list but it didn’t go out
+2016-06-12 21:44:02< Soap___> ulm: is L10N introduced in a new EAPI or EAPI>=5?
+2016-06-12 21:44:49<@ulm> really, in all EAPIs
+2016-06-12 21:45:10<@ulm> which practically means >= 5 nowadays
+2016-06-12 21:45:42<@ulm> it's not related to any PMS changes
+2016-06-12 21:46:39<@ulm> ok, I don't think we need a decision of the council here
+2016-06-12 21:46:51<@dilfridge> L10N makes sense.
+2016-06-12 21:47:14<@ulm> yeah, and we should go for BCP 47
+2016-06-12 21:47:17<@ulm> as in https://en.wikipedia.org/wiki/IETF_language_tag
+2016-06-12 21:47:21< Soap___> sure
+2016-06-12 21:47:30<@K_F> the change seems to make sense to me, the process for implementing it should reduce user impact and be properly tested
+2016-06-12 21:47:40<@blueness> ulm: i’ll totally trust you on this one because i suck at locales :)
+2016-06-12 21:48:30<@K_F> not just be changed and thrown over to individual devs to fix it it immediately.. so if things can be done to existing ebuilds to reduce the impact, it should be tracked
+2016-06-12 21:48:55<@ulm> K_F: there will be a transition period for sure
+2016-06-12 21:49:38<@blueness> are there anymore comments before we move on?
+2016-06-12 21:49:47<@blueness> okay next item
+2016-06-12 21:50:12<@blueness> 3. Open bugs with council involvement  - https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&email2=council%40gentoo.org&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype2=substring&list_id=3196564&query_format=advanced
+2016-06-12 21:51:07<@K_F> any update on the two missing summaries?
+2016-06-12 21:51:24<@K_F> those are the only I see that require action atm
+2016-06-12 21:51:26<@ulm> dilfridge!
+2016-06-12 21:51:31<@dilfridge> huh
+2016-06-12 21:51:32<@ulm> :)
+2016-06-12 21:51:38<@dilfridge> yeah. next time...
+2016-06-12 21:51:59<@blueness> K_F: i just completed the march 2016 and emailed it to everyone i’ll upload it after the meeting
+2016-06-12 21:52:16<@ulm> april also done
+2016-06-12 21:52:18<@K_F> blueness: good
+2016-06-12 21:52:28<@K_F> ulm: yeah, that looked good to me
+2016-06-12 21:52:53<@blueness> i don’t knwo what to do about the games.eclass and games team
+2016-06-12 21:53:06<@blueness> i dont’ think opening more bugs and cc-ing us will make a difference
+2016-06-12 21:53:40<@rich0> blueness: I don't know that we need to do anything.  We approved moving forward.  Somebody just needs to step up and do the work.  If nobody cares enough to, then it must not bother them too much.
+2016-06-12 21:53:45<@WilliamH> I've got the log for May 2016, but I don't think there'll be much to summarize; the agenda was just open bugs.
+2016-06-12 21:53:45<@K_F> blueness: agreed, although aren't packages with issues being reduced anyways due to the repoman failures?
+2016-06-12 21:53:56<@dilfridge> basically
+2016-06-12 21:53:57<@rich0> We can't just pester other people to do things our way.
+2016-06-12 21:54:10<@dilfridge> we need someone who just steps up and starts fixing games
+2016-06-12 21:54:30<@blueness> okay what about the ChangeLog
+2016-06-12 21:54:33<@dilfridge> then of course games team will start complaining, but such is life, and they can get safely ignored
+2016-06-12 21:54:35<@rich0> agree, but until that happens there is not much to be done.  we did clear the way for them, but we can't make somebody do the work
+2016-06-12 21:54:39<@K_F> I'm with rich on this one, if anyone cares enough to do it they have approval to do so
+2016-06-12 21:55:00<@rich0> It is like fixing functions.sh - somebody just needs to start writing patches.  :)
+2016-06-12 21:55:16<@ulm> blueness: I've CCed council to bug 565566 mainly to keep us up-to-date
+2016-06-12 21:55:18< willikins> ulm: https://bugs.gentoo.org/565566 "New ChangeLogs are in chronological order"; Gentoo Infrastructure, CVS/SVN/Git; CONF; patrick:infra-bugs
+2016-06-12 21:55:25<@WilliamH> rich0: which functions.sh?
+2016-06-12 21:55:30<@ulm> because we had a vote in April
+2016-06-12 21:55:32<@rich0> WilliamH: your favorite one :)
+2016-06-12 21:55:40<@blueness> ulm: okay it looks like you guys have it under control
+2016-06-12 21:55:41<@K_F> that was discusessed in an earlier meeting and iirc the decision is included there
+2016-06-12 21:55:44<@WilliamH> rich0: heh, I'll take a look at it.
+2016-06-12 21:56:08<@rich0> There is already a tracker - it really bothers me, but I'm not going to complain because the reality is that I could start fixing things myself...
+2016-06-12 21:57:06<@WilliamH> rich0: are we talking about other packages that should be sourcing it?
+2016-06-12 21:57:19<@rich0> WilliamH: exactly - as in where they should be sourcing it from.
+2016-06-12 21:57:34<@rich0> Sorry guys for sidetracking us.
+2016-06-12 21:57:52<@dilfridge> as an example, I've made a copy of stable gcc-config in my overlay and applied the functions.sh patch.
+2016-06-12 21:58:10<@dilfridge> I'm very much tempted to just push that into a straight-to-stable revbump.
+2016-06-12 21:59:27<@ulm> hm, have we just lost our chairman?
+2016-06-12 21:59:29-!- mode/#gentoo-council [+o blueness] by ChanServ
+2016-06-12 21:59:41<@ulm> wb :)
+2016-06-12 21:59:49<@K_F> I'm not generally fond of s2s anything :)
+2016-06-12 22:00:18<@WilliamH> K_F: s2s?
+2016-06-12 22:00:25<@K_F> WilliamH: straight to stable
+2016-06-12 22:02:33< Soap___> blueness: what about the mgorny items?
+2016-06-12 22:02:42< Soap___> specifically that one GLEP?
+2016-06-12 22:02:45<@K_F> but is the function.sh what is currently causing the systemd and openrc conflict ?
+2016-06-12 22:03:17<@ulm> Soap___: earlier we said we would only do 2c and 2d today
+2016-06-12 22:03:18<@K_F> I notice users are told in wiki now (and saw some discussion on it in #gentoo) to remove openrc from @system
+2016-06-12 22:03:19<@WilliamH> K_F: sometimes s2s is ok, it depends on what you are doing.
+2016-06-12 22:03:34<@ulm> Soap___: glep was 2a
+2016-06-12 22:03:46< Soap___> ulm: I know, but the convo seemed to have died
+2016-06-12 22:03:55<@blueness> damn, someone is going to ahve to email me the logs :(
+2016-06-12 22:03:57<@blueness> mac colloquy = suck!
+2016-06-12 22:03:58<@blueness> sorry guys i’ve lost track of the conversation, are we done with open bugs?
+2016-06-12 22:03:59<@blueness> hello?  can anyone hear me?
+2016-06-12 22:04:00<@blueness> Soap___: we’re not doing the others today
+2016-06-12 22:04:06<@K_F> blueness: I have the logs
+2016-06-12 22:04:07<@WilliamH> Wow, users shouldn't be removing things from @system
+2016-06-12 22:04:15<@blueness> Soap___: i think we’re done with open bugs, so we’ll go to open floor
+2016-06-12 22:04:26<@K_F> WilliamH: https://wiki.gentoo.org/wiki/Systemd#Installation
+2016-06-12 22:04:37<@K_F> ok, since this was the last official meeting of the current council, let me just say thank you for a good cooperation in the past year to everyone!
+2016-06-12 22:04:40<@blueness> K_F: thanks if you can email them afterwards i’d appreciate it
+2016-06-12 22:04:40<@ulm> blueness: no closed session for that appeal then?
+2016-06-12 22:04:51<@blueness> omg yes!
+2016-06-12 22:04:57<@blueness> sorry i forgot!!!!
+2016-06-12 22:05:01<@dilfridge> right
+2016-06-12 22:05:01<@K_F> ulm: I suggest open floor first in any case
+2016-06-12 22:05:09<@ulm> K_F: wfm
+2016-06-12 22:05:19<@blueness> lets’ do open floor and then we have a private session
+2016-06-12 22:05:47<@blueness> okay anything for open floor?
+2016-06-12 22:06:05<@K_F> I only have my above statement :)
+2016-06-12 22:06:23<@blueness> if not we’ll continue in #gentoo-council-private
+2016-06-12 22:06:38<@blueness> does anyone know how to let Soap___ in?  /invite?
+2016-06-12 22:06:52<@dilfridge> hmm let's see
+2016-06-12 22:06:54<@WilliamH> blueness: /invite should work.
+2016-06-12 22:07:05< Hello71> yes, assuming you don't have any akicks set.
+2016-06-12 22:07:24< Hello71> although it's possible you'll have to set -f first
+2016-06-12 22:07:46<@blueness> Soap___: cna you joing #gentoo-council-private
+2016-06-12 22:21:42<@blueness> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
+2016-06-12 22:27:32<@ulm> blueness: thanks for chairing :)
+2016-06-12 22:28:24<@blueness> ulm: no problem
+2016-06-12 22:31:53< Soap___> mgorny: why did you decline council nomination?
+2016-06-12 22:33:49<@ulm> dilfridge: libreoffice-l10n would make a good first package for conversion from LINGUAS to L10N
+2016-06-12 22:34:08<@ulm> because a) it would populate the new var with > 100 values
+2016-06-12 22:34:42<@ulm> and b) LO uses bcp 47 already
+2016-06-12 22:36:15< mgorny> Soap___: do i look like i have time for that? ;-p
+2016-06-12 22:37:27< Soap___> mgorny: does jlec look like he has time for it? :P
+2016-06-12 22:41:40< mgorny> Soap___: why don't you become president of gentoo?
+2016-06-12 22:42:41< Soap___> mgorny: to then have a fight with ciarian two weeks later and get booted? :P