[20:02:02] shall we start? [20:02:02] <-> ulm_ heißt jetzt ulm [20:02:18] 1. Roll call (5 minutes) [20:02:20] -*- dilfridge here [20:02:24] here [20:02:30] -*- rich0 here [20:02:35] Here [20:02:44] -*- WilliamH here [20:03:12] ulm, blueness? [20:03:24] here [20:03:34] just in time for the meeting I am having connection issues :( [20:03:36] -*- ulm here [20:03:43] ok everyone's here! [20:04:03] 2. Discussion of GLEP39, "lame projects" / "lame project leads" (10 minutes) http://thread.gmane.org/gmane.linux.gentoo.project/4169/focus=4170 [20:04:11] rich0: your moment [20:04:32] Was that one mine? [20:04:35] lame -> unresponsive I assume [20:04:43] err sorry [20:04:49] blueness: your moment :) [20:05:02] well [20:05:02] -*- rich0 breathes a sign of relief [20:05:32] there was a lot of chatter on the list, but basically i wanted to see what the council thinks we ought to do with lame team leads [20:06:07] in particular toolchain. it doesn't have a project page, i'm not sure whos lead, i think its vapier, but vapier isnt' very responsive [20:06:29] so i want to help with toolchains, but can't interact with its organization [20:06:32] blueness: if it doesn't have a project page it isn't really a project? [20:06:39] in this particular case it's even more complicated since it's no project (no page)... [20:06:43] no idea, it *is* a herd [20:06:49] blueness: I've seen toolchain as more a subproject of base-system. [20:06:51] and glep39 only talks about projects... [20:07:08] WilliamH, is it? [20:07:15] All of these issues are related. [20:07:30] Well, it is more like just a group of maintainers. [20:07:36] We have lots of loose associations of packages and devs with varying levels of formality, and varying levels of leadership/etc. [20:07:37] udev-bugs is similar. [20:07:44] glep 39 isn't so much about laying down the law as expectations [20:08:02] I'll agree with that. I think there needs to be flexibility. [20:08:14] Also, I think that to some degree devs need to "be bold" in Wikipedia terms. [20:08:28] ie not wait around forever for an email response that will probably never come [20:08:44] rich0: I can agree with that... I have personally been cautious about that myself in ways, but you are right. [20:08:48] rich0, i think some boldness is needed too, but its really hard when you are naturally a "team player' not that i like that erm [20:08:51] term [20:09:17] the base system project page states that the base system project kinda maintains the toolchain, though it does not list toolchain as one of its herds [20:09:23] classic bug to illustrated the issue -> https://bugs.gentoo.org/show_bug.cgi?id=516988 [20:09:23] what exactly are you wanting to do here? rework/redo the toolchain eclass and need feedback? [20:09:43] <-- dberkholz|mob (~AndChat19@gentoo/developer/dberkholz) hat das Netzwerk verlassen (Disconnected by services) [20:10:23] radhermit, no just get some toolchain stuff done, eg the next one is shooting for gcc 4.9.2 stabilizatoin [20:10:40] --> dberkholz|mob (~AndChat19@gentoo/developer/dberkholz) hat #gentoo-council betreten [20:10:48] so there really hasn't ever been a leader coordinating such things in recent history [20:10:50] blueness: imo if no one responds in a reasonable amount of time add yourself and go for it. [20:11:05] just the main gcc maintainer at the time [20:11:06] Agree with the solution to the immediate problem. [20:11:21] radhermit: yes, it was mostly the gcc maintainer. [20:11:21] I think the real question is does this need fixing, and can it be fixed? [20:11:39] radhermit, in part just filling in the nitty griddy stuff with rhill being gone [20:11:39] rich0: I'm not sure there is anything to fix here. [20:11:56] IMO I think our options are limited. If somebody doesn't want to actually step up and be a charismatic leader / etc, then at most we can just put barriers in the way of people who don't want to do that. [20:12:01] the toolchain eclass is there too, but i don't want to focuse on that [20:12:09] basically someone needs to step up, and we can't really do anything as a council to effectively make that happen [20:12:12] that is a different porblem [20:12:37] the biggest problem is "trying to join a team, but there is noone who responds" [20:12:45] radhermit, i'm okay with coordinating it, but vapier is the technical wizard here [20:12:52] blueness: I say go for it; no one is stopping you from adding yourself. [20:12:55] yup, I don't think not having any toolchain team is better than having one with a non-responsive lead [20:13:13] -*- dilfridge has some doubts about the wizard level since the botched dependency fixes [20:14:01] okay, so zorry and i spoke about this in pm and we'd like to start coordinating toolchain [20:14:24] so maybe i'll get a page up as a subproject of base system [20:14:31] sounds fine to me [20:14:31] sounds good [20:14:38] blueness: nothing is stopping you from formalizing it into a project. [20:14:44] and then at least there'll be some point-of-contact [20:15:14] blueness: it doesn't have to be a subproject of base-system even imo that's up to you. [20:15:22] to be honest, i didn't care so much about games team or other teams being disorganized, but its worrisome when toolchain is this way [20:15:37] yes, but it's a repetitive problem [20:15:52] okay, i don't think we need a motion here or anything, i just wanted to bounce this off the council for feedback [20:16:05] toolchain, portage at times, sometimes infra. There are a lot of overworked/understaffed/etc projects that are fairly core to the distro [20:16:06] maybe we should come up with a general idea how to solve it [20:16:11] I think teams are disorganized in general, with organization being the rarity here [20:16:16] zorry and i had a similar situation with hardened back in the day when gengor + solar were fading away [20:16:47] To some extent it might reflect an attitude that these things are mature and don't need a lot of improvement [20:16:48] scarabeus seems to be missing in action, so office is only me right now... [20:17:06] isn't it straight forward? apply to join the project/team, and if there is no reply from project members for some time then you just add yourself [20:17:11] radhermit, if you see vapier in real life, just let him know what i'm up to. and reassure him we (zorry and i) are only shooting for conservative commits [20:17:28] sure, might see him tonight [20:17:29] ulm: that is exactly what I'd suggest to put somewhere in writing. [20:18:04] lead MIA can be handled in a similar way [20:18:08] that's exactly what I've always done... other people are just too hesitant I guess :P [20:18:13] As someone told me, the lead of a project doesn't have to be the technical wizzard. The lead just coordinates the project. [20:18:13] Agree. In general if the previous team is unresponsive, just step up and make a new one, etc. [20:18:33] WilliamH++ [20:18:46] really the technical wizard types should probably be doing work, not coordinating stuff [20:19:21] works for me [20:19:26] Agree. We don't want people who are outright disruptive, but if somebody wants to quietly do their own thing and it is making Gentoo better, then we should get out of their way. [20:19:32] do we need / want a resolution? [20:19:55] dilfridge, i don't think we need a motion here [20:20:06] fine with me [20:20:08] -*- WilliamH agrees with blueness [20:20:10] anyone else? [20:20:11] I think we should try to send out a general mesage though. It isn't about rules. [20:20:20] "Ask if you can add yourself... after X amount of time with no response, add yourself." [20:20:23] something like that [20:20:26] toolchain is important and i want to make sure the council is okay with trying to re-organize it [20:20:28] radhermit: ++ [20:20:35] s/x/a reasonable/ [20:20:52] And they can always escalate to council if there is conflict. However, if it is person vs wall of silence, the person can just assume the answer is yes. [20:21:01] radhermit, i almost always agree with that statement, but i'm not so sure when it comes to the more demanding stuff [20:21:08] +1 on that (self-adding w no response) [20:21:19] eg. i'm not sure if non-response about binutils should mean anyone gets to add binutils! [20:21:26] Making that explicit if it's not yet would be a good thing [20:21:30] blueness: if some random person starts breaking important stuff they'll get noticed ;) [20:21:36] true! [20:21:40] and things will become less silent [20:21:45] yes yes [20:21:47] and qa wakes up [20:21:49] :) [20:22:00] actually the way i usually add toolchain stuff is keyword masked [20:22:01] radhermit: agree, right now I think we're erring on the side of too little risk, and not enough is getting done [20:22:10] so it can't break stuff right away [20:22:19] If things start breaking then we can deal with that problem [20:22:21] but its there for testing [20:22:37] ok I think we're all basically of the same opinion. [20:22:50] any completely different statements? if not, ... [20:23:11] good, so expect some toolchain stuff to be comeing from me and zorry, eg stabilization of gcc-4.9 etc [20:23:21] sounds excellent [20:23:36] Next topic... [20:23:36] 3. Policy for long-term package masks (10 minutes) http://thread.gmane.org/gmane.linux.gentoo.project/4169/focus=4198 [20:24:04] Really what I was wanting was to get some folks to step up and update them or fix things. [20:24:05] dunno how much we need to talk there [20:24:18] and that is happening. [20:24:31] i would kinda prefer to see them move to overlays if they're gonna be long-term [20:24:48] some issues relate to games that have bundled libs I'm assuming, kind of hard to fix that [20:24:48] and use p.mask for breakage [20:24:49] -*- WilliamH tends to agree with dberkholz to be honest [20:25:09] as long as a package is actively maintained, I don't have a problem with long-term masks [20:25:31] ulm, there is one example of where that might make sense [20:25:32] but we should avoid broken and unmaintained stuff sitting in the tree for years [20:25:42] is taviso still around ? [20:25:44] paxtest is a package which is *intentionally* broken [20:25:47] as long as there is a good description what the mask is for, I don't mind either (why? impact? duration?) [20:25:51] taviso isn't around [20:25:53] -*- WilliamH points to the very bottom of p.mask [20:26:20] works on google security stuff atm iirc [20:26:37] radhermit: is he still an active gentoo maintainer? [20:26:42] in general masked packages are better gone, but there are valid reasons to keep them around [20:26:45] WilliamH: nethack? that was discussed on lists [20:26:55] broken by games policy [20:27:11] no [20:27:12] sorry [20:27:16] WilliamH: he's not even a dev afaik [20:27:17] is he even an active gentoo dev? i don't think so [20:27:20] retired him [20:27:26] bug 44351 [20:27:27] # (01 Apr 2004) [20:27:28] yeah [20:27:29] WilliamH: https://bugs.gentoo.org/44351 "games-fps/unreal engine vulnerability"; Gentoo Security, Vulnerabilities; VERI, CANT; carlo:security [20:28:07] masked for 11 years now? [20:28:20] actually I wonder if this still runs [20:28:26] in addition these are cdrom installs, so nobody can check status [20:28:49] is unreal free these days? [20:28:56] that was on the lists [20:28:56] such stuff should be removed, or moved to an overlay [20:28:56] yes [20:29:10] -*- WilliamH agrees with ulm [20:29:12] I'm not convinced that games with issues like this can't be in the tree [20:29:20] i agree with ulm above, the key point is whteher its being actively maintained, not the masking [20:29:21] However, I think that should only be if they're maintained [20:29:35] if they're maintainer-wanted and nobody can even tell if they work, then I'm fine with treecleaning [20:30:05] Anything that isn't open-source should be treecleaned if not maintained - nobody can even vouch for whether it works [20:30:16] Is "This is a fun game so I think it should be kept" valid? [20:30:24] rich0: +1 [20:30:27] it's a different story if there's a maintainer who can confirm that it still works [20:30:44] ;-) [20:30:53] just to be clear: something that works but puts users at risk is "maintained" by your definition? [20:30:59] WilliamH: imho not if there's a big security problem with it [20:31:00] a3li: yes [20:31:10] I'm fine with it being masked and in the tree. [20:31:14] Let the user make the choice [20:31:19] solution: try last-riting stuff you want to remove and see who cares ;) [20:31:38] radhermit: I did, that's why we are talking about it. [20:31:44] I'm more concerned with it being unmaintained and untestable than it being insecure [20:31:56] a3li: what's the official security steam statement about keeping security-problematic packages in the tree masked? [20:32:01] security is a continuum, with risk up to to the user [20:32:23] dilfridge: practice has been to remove known vulnerable packages for years (n>5); only keep if needed for good reasons [20:32:24] a3li: (or how is it handled now, mostly?) [20:32:29] what about a package that simulates security risks as part of a test suite? [20:32:35] When I've had security bugs on packages I maintain I've been asked to remove vulmerable versions after the fixed one is stable. [20:32:47] blueness: that doesnt count imho, but it needs to be documented. [20:32:50] dilfridge: and statement: keep that policy. [20:32:51] WilliamH: sure, if there is a non-vulnerable version [20:32:55] dilfridge, it is [20:33:04] What if latest version is insecure, and this is unlikely to change? [20:33:24] paxtest intentionlly tries to execute code in the stack, bss, data etc to see if the pax kernel catches the problem [20:33:27] kick, kill, move to overlay [20:33:29] rich0: I disagree with you wrt keeping vulnerable software in the tree (qa hat firmly on) [20:33:30] ?! [20:33:31] rich0: remove, unless there are good reasons for keeping it [20:34:01] WilliamH: you're allowed to disagree, but I'm not changing my mind [20:34:19] ok [20:34:20] ulm: the good reason for keeping it is that it is useful [20:34:36] -*- WilliamH disagrees [20:35:10] security depends on context, so let the user decide [20:35:11] WilliamH: everything you use has a security vulnerability. They're just unknown at present. [20:35:22] on the list, there was the example of sys-block/afacli which depends on a package with security issues, but there is no alternative [20:35:40] "fun game" is in my opinion not a good reason [20:35:52] -*- WilliamH agrees with dilfridge [20:35:54] what is the alternative to unreal? [20:35:58] so if it was removed, users would still install it from elsewhere [20:36:16] ulm: agree [20:36:22] rich0: we aren't saying you can't use it, just that it belongs outside the main tree [20:36:25] ulm: true but not our problem, since we're not providing it [20:36:29] We're not making anything more secure. We're just forcing everybody to stick things in overlays [20:36:55] rich0: we are cleaning up the main tree [20:36:56] WilliamH: you prefer an overlay with no security warnings to an in-tree package with them? [20:37:07] Why even have a main tree? [20:37:14] imo, if we ever move to a more multi-repo centric approach then moving to repos makes sense, currently we're not really pushing that so it doesn't imo [20:37:58] rich0: but we're providing a maintainership / security / ... "guarantee" for the main tree, and for nothing else [20:38:22] dilfridge: we're not breaking that guarantee [20:38:27] We clearly disclose that the package is vulnerable [20:38:35] Which is more info than users would get otherwise [20:39:20] ok [20:39:26] we have control over the tree and so can assure quality there, but not with repos, so be careful about moving stuff to repos [20:39:37] this is not really going anywhere, we have different opinions [20:39:48] Should we vote on whether packages with security vulnerabilities shoulb be removed from the tree if there are no fixed versions? [20:39:52] I'd propose a vote: [20:40:33] "may packages with security vulnerabilities remain in tree package-masked for indefinite time?" [20:40:48] -*- WilliamH votes no [20:40:51] -*- dilfridge no [20:40:55] I suggest rewording [20:40:58] "assuming there are no replacements for them and they have maintainers" [20:41:06] tack that on [20:41:09] ok, that is good [20:41:10] *active* maintainers [20:41:16] "May maintained packages with security vulnerabilities remain in tree package-masked for indefinite time?" [20:41:29] "may packages with security vulnerabilities remain in tree package-masked for indefinite time, assuming there are no replacements for them and they have active maintainers?" [20:41:46] -*- dilfridge votes still no [20:41:51] -*- ulm votes yes [20:41:54] -*- blueness yes [20:41:55] yes [20:42:11] Assuming above, yes. [20:42:42] dberkholz: rich0? [20:42:47] Now my question to the council is, is "games" an active maintainer? I would assume no. [20:42:55] or radhermit's suggestion [20:43:02] dilfridge: what? [20:43:08] lag [20:43:12] -*- rich0 yes [20:43:58] Actually, one more thing. [20:44:01] WilliamH: given that I see activity by Mr_Bones updating EAPIs, I would say yes. [20:44:41] looking again at the mask I cited, [20:44:55] the mask was put there by kleiber and has never been touched. [20:45:03] WilliamH: plenty of the games are probably rotting and could be last-rited if Mr_Bones or whoever doesn't step up say they're still maintained [20:45:10] so from that pov, kleiber did the masking. [20:45:23] I'm sure he doesn't care about every single game some random dev has added with "games" as the herd and then retired after a few years [20:45:42] radhermit: right. [20:45:55] when we're done voting, can we have a followup on the resolution [20:46:05] He hasn't stepped up wrt the last rites I posted. [20:46:06] i'd vote no [20:46:13] i think we should add a few comments if we email this decision out [20:46:14] overlays are fine [20:46:27] (bad connectivity in here, sorry) [20:46:37] WilliamH: so CC games/him and wipe them later? [20:46:42] I would add a qualification... [20:47:26] radhermit: why cc games? it was put on g-d-a and dev [20:47:32] ok that means 2x no, 5x yes, motion passed [20:47:47] WilliamH: I dunno, you were sounding hesitant [20:48:04] dilfridge, okay now that we have a yes vote, i think we should also strongly recommend the maintainer communicate the issue to the user [20:48:16] yes [20:48:18] But I think we should be able to push the maintainer to get a fixed version in the tree and remove the old ones. [20:48:26] say in a pkg_postint say [20:48:39] there should be some mitigation of the risk [20:48:53] how much stronger can you get than a mask stating the vulnerability? [20:48:55] eg. if you want to play nethack, do it in a sandbox [20:48:58] blueness: if you do that with pkg_postinst it doesn't belong in p.mask. [20:49:19] sorry your right [20:49:23] p.mask is not permanent. [20:49:24] it does say pmasked [20:49:33] but then we should have the info in the pmask comment [20:49:43] if/when people unmask stuff, they should know what they're getting into [20:49:44] s/info/warning/ [20:49:57] yes, as long as there's info [20:50:01] If we are going to allow security vulnerable packages to stay in the tree they don't belong in p.mask, use postinst msgs [20:50:22] isn't that exactly what the mask message is for? [20:50:25] yes [20:50:28] p.mask is for things that can be fixed. [20:50:29] radhermit, i'm good, it just slipped my mind that p.mask has that comment when you try to emerge [20:51:00] p.mask is for masking things, full stop [20:51:10] I was always taught that p.mask is never permanent. [20:51:41] ok [20:51:53] do we want to make another vote / motion? [20:52:08] just to chime in as a security type: which makes more sense, a big warning that says "security issues, unmask at your own risk" or an easily-ignored postinst? [20:52:09] dilfridge, for the warning? [20:52:41] "the security issue must be documented in the mask message, with bug number" [20:52:48] sounds fine [20:52:56] -*- blueness yes [20:53:05] -*- rich0 yes [20:53:07] -*- dilfridge yes [20:53:13] -*- radhermit yes [20:53:39] -*- ulm yes [20:53:41] of course.. [20:53:54] k [20:54:00] anything else to say here? [20:54:31] seems not [20:54:32] I se this as an abuse of p.mask to be honest. [20:54:39] (ab)use [20:55:27] 4. Open bugs with council involvement (5 minutes) [20:55:27] and I wish all games released source code after X number of years [20:55:28] WilliamH, it really does depend if this just becomes an easy way around trying to fix something or a last resort [20:55:39] http://devmanual.gentoo.org/profiles/package.mask/index.html [20:56:27] blueness: indeed. so let's start lastriting ancient stuff and see what happens. [20:56:30] anyway [20:56:32] 4. Open bugs with council involvement (5 minutes) [20:56:38] bug 523828 [20:56:40] dilfridge: https://bugs.gentoo.org/523828 "GLEP 42 update: Unify gentoo-news repo and rsync structure"; Doc Other, GLEP Changes; CONF; mgorny:glep [20:56:49] any news here? [20:57:19] dilfridge: I agree with you, let's start getting rid of ancient stuff. [20:57:40] since we decided about it last time, maybe we should just un-cc council and leave the execution to, well, some able executioners? [20:57:58] someone should update that glep [20:58:22] the generation code is more critical [20:58:42] it's a trivial change [20:59:02] yes but someone needs to do it. wink, wink, wink... [20:59:27] the proponent? :) [20:59:34] ok seems nothing to do here. [20:59:44] bug 503382 [20:59:49] dilfridge: https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council [20:59:59] well, nothing to do here either. just move along please. [21:00:15] 5. Open floor [21:00:18] anyone? [21:00:40] Well, I'll just comment. [21:00:55] Today's debate is a good example of why devs find it hard to be bold and do things. [21:01:05] *sigh* [21:02:12] i'm not sure bold/courage is the right issue, its more respect [21:02:20] and coordinating with other devs [21:02:32] about masks? I still don't see what the issue is about removing ones if no one cares enough to respond for certain pkgs. [21:03:02] that's what last rites are partially for, questioning maintainership [21:03:21] I need to go through the thread again, but I believe I saw someone say that "x is a fun game, so this should be kept in the tree regardless of the risk" a couple of times. [21:03:49] WilliamH: if it were maintained I'd agree with them [21:03:51] if they didn't want to step up and maintain it... too bad I'd say [21:03:53] WilliamH: noone prevents you from starting last rites, and if "someone" doesnt volunteer to maintain it, then "someone" doesn't really count [21:03:58] I also saw one that was "Now there is a new version of x that is gpl'd, but we should keep both." [21:04:06] dilfridge: ++ [21:04:26] WilliamH: might be worth exploring the reasoning behind such a statement in the latter example [21:04:41] In general though I'm more about informing users than making choices for them [21:05:02] --> keytoaster (~tobias@gentoo/developer/keytoaster) hat #gentoo-council betreten [21:05:06] Stuff that is just broken or which we can't be sure if it is broken or not, that is a different story. There is no value to having ebuilds in the tree that don't even build [21:05:13] ++ [21:05:21] are you arguing that insecure software isn't broken? [21:05:26] The justification was pretty weak, just like the argument we had a while back about keeping module-init-utils. [21:05:48] -*- WilliamH thinks insecure software is dangerously broken [21:06:01] insecure software that you aren't able to fix but have to use is broken in a special way :) [21:06:26] and with these words, it's about time... I dont think this further discussion is going anywhere. [21:06:37] new arguments next month please. [21:06:46] What about the "gentoo is about choice" argument? [21:06:47] -*- dilfridge bangs the gavel [21:07:01] session closed