path: root/meeting-logs/20160612.txt

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