diff options
Diffstat (limited to 'meeting-logs/20141203.txt')
| -rw-r--r-- | meeting-logs/20141203.txt | 487 |
1 files changed, 487 insertions, 0 deletions
diff --git a/meeting-logs/20141203.txt b/meeting-logs/20141203.txt new file mode 100644 index 0000000..463d60e --- /dev/null +++ b/meeting-logs/20141203.txt @@ -0,0 +1,487 @@ +Timestamps are in UTC+3 + +[22:05:53] <zlogene> ok, first meeting after months +[22:06:13] <Pinkbyte> creffett, i can do it, start recording log right now just in case... +[22:06:18] <creffett> Pinkbyte: okay +[22:06:46] * zlogene writes logs too +[22:06:51] <zlogene> fyi +[22:06:59] <creffett> so, let's start with elections +[22:07:17] <creffett> if you want to run, please email the alias saying as much and with a short statement of why people should vote for you +[22:07:41] <creffett> we'll leave that open until next tuesday, at which point I'd like to do a helios vote, same as what we did last year +[22:07:45] <creffett> any objections? +[22:07:56] * zlogene is ok +[22:08:02] <mgorny> no objections, move forward ;P +[22:08:05] <ulm> ok +[22:08:17] <Tommy[D]> ok +[22:08:26] <Pinkbyte> creffett, everything is clear, ok +[22:08:35] <wired> +1 +[22:08:45] <creffett> that said, I strongly suggest people step up to run, it would be very sad if QA were without a lead +[22:09:18] * wired doesn't have enough time for this, unfortunately +[22:09:42] <zlogene> creffett, do you plan to continue your leadership, btw? +[22:09:47] <creffett> zlogene: I do not +[22:10:11] <Pinkbyte> That would be sad, i think you are doing very well +[22:10:18] <ulm> +1 +[22:10:31] <creffett> I disagree with you, but that's a discussion we can have outside of meeting time +[22:10:40] <creffett> back to the agenda: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Inquiry +[22:10:56] <creffett> TomWij isn't here to talk about it, unfortunately +[22:11:11] <creffett> agenda says to review it. Do we have any input? do we like it? do we care? +[22:11:22] <Pinkbyte> creffett, my opinion after quick look - this should be posted officially as is, no major changes required +[22:11:41] <ulm> IMHO doesn't make sense to discuss without TomWij +[22:11:50] <Pinkbyte> and yes, we care. Clearly said what is QA area of responsibility is a good point +[22:11:54] <ulm> and it's already online ;) +[22:11:58] <creffett> well, according to the Wiki page, TomWij isn't part of the team, so... +[22:12:04] <creffett> that's a bit of an issue +[22:12:12] <zlogene> in general it looks good to me +[22:12:27] <creffett> personally I'm happy with it in general, but would like to rewrite it to be more concise +[22:13:06] <Pinkbyte> creffett, o_O. How it's possibly? I saw him in our project page with a 'Deputy lead' in description. Probably something breaks :-/ +[22:13:31] <zlogene> Pinkbyte, his account has been deleted it seems +[22:13:36] <creffett> Pinkbyte: he removed himself from pretty much all of his projects a couple weeks ago +[22:13:39] <creffett> !away TomWij +[22:13:40] <willikins> creffett: tomwij: I am taking a break from Gentoo. I don't think I'm ready to retire, but I think I need a break to decide. Still present to talk if you can catch me... @ 2014/09/10 12:28Z +[22:13:45] <ulm> Pinkbyte: https://wiki.gentoo.org/index.php?title=Project%3AQuality_Assurance&action=historysubmit&diff=165052&oldid=157850 +[22:13:45] <creffett> ^^ there we go +[22:14:25] <creffett> so let's put this off until next meeting, I will rewrite it a little to make it more understandable +[22:14:32] <ulm> and he was doing well, too +[22:14:35] <ulm> IMHO +[22:14:45] <Pinkbyte> That's sad too. We have some disagreement with him in a past, but he did a good job. Hope he will come back +[22:15:22] <creffett> yeah, well, it is what it is +[22:15:43] <creffett> any other input on the Inquiry article for now? +[22:15:57] <zlogene> no +[22:16:34] <Pinkbyte> creffett, no, as i said - i think it's good to go right now, but if you want to reword it to be more clearer - i do not mind +[22:16:39] <creffett> Pinkbyte: okay +[22:16:53] <creffett> next topic, then +[22:16:59] <creffett> Review the games team policies: games group, forcing /usr/games when upstream does not use it, games.eclass (points 3-5 in mgorny's reply of last Council agenda, deferred by Council to be discussed by QA). +[22:17:06] <creffett> mgorny: talk to us +[22:17:08] <mgorny> yay, finally +[22:17:29] <mgorny> so pretty much council said we don't have to use games.eclass but specific policies should be discussed by qa +[22:17:42] <mgorny> games team had no input except that i'm stupid +[22:17:46] <creffett> as expected +[22:17:55] <creffett> mgorny: what specifically do you want us to vote on? +[22:17:55] <ulm> kill it with fire +[22:18:01] <ulm> the eclass, that it +[22:18:03] <ulm> *is +[22:18:03] <mgorny> i think we should decide on some goals to get things consistent +[22:18:11] <zlogene> as usual... +[22:18:13] <mgorny> 1) install stuff as upstream wants (preferably to /usr) +[22:18:28] <creffett> mgorny: does games.eclass provide any utility other than forcing /usr/games and the games group? +[22:18:34] <mgorny> 2) remove games group as currently defined, open access to games +[22:18:45] * ulm notes that the FHS has /usr/games, /usr/share/games, and /var/games +[22:19:05] <mgorny> creffett: i think there's one function to do wrappers and one unpacker +[22:19:07] <ulm> with binaries directly in /usr/games, not /usr/games/bin +[22:19:13] <Pinkbyte> creffett, i wrote some games ebuilds using games.eclass. And - basically no. Only plenty of functions to force such behaviour +[22:19:17] <mgorny> but the wrappers are probably /usr/games-related +[22:19:18] <creffett> k +[22:19:22] <mgorny> and the unpacker is in unpacker.eclass too +[22:19:35] <creffett> okay then +[22:19:45] <Pinkbyte> ulm, yeah, some FHS compatibility is one thing that stops me to say 'god damn, just go with games like with any other normal application in Gentoo!" +[22:20:11] <creffett> so stop forcing weird install locations, kill games group, eventually kill games.eclass (and make it non-mandatory for now)? +[22:20:25] <mgorny> it's non-mandatory already but some developers are confused +[22:20:40] <mgorny> and some people (games team?) tell others to use it +[22:20:41] <creffett> games team says otherwise ;) +[22:21:09] <creffett> anyone have comments on these before we vote? +[22:21:10] <mgorny> which brings up to things like gnome wasting time converting their ebuild to games.eclass +[22:21:22] <mgorny> because someone told them to +[22:21:24] <ulm> mgorny: so usual rules, install to /usr +[22:21:27] <ulm> and /opt if it's a binary pkg? +[22:21:38] <mgorny> yes, if you believe so +[22:21:53] <mgorny> though i think /opt is more like /opt/company/fancything +[22:22:02] <mgorny> when it can't work with /usr layout +[22:22:54] <Pinkbyte> mgorny, in Gentoo i often see that /opt is used for binary-only stuff +[22:23:08] <mgorny> i know +[22:23:19] <mgorny> but that's another topic, so let's not bother ourselves with it +[22:23:24] <ulm> actually, do we have a policy on this? +[22:23:29] <mgorny> maybe i'll write a GLEP for simple filesystem layout at some point +[22:23:42] <mgorny> i'm sure people will be very happy to see it +[22:23:51] <creffett> ulm: I'm not certain, I know that's unofficial policy for a long time at least +[22:24:21] <mgorny> another common choice is /usr/lib/whatever +[22:24:25] <mgorny> i think FHS allows both +[22:24:33] <mgorny> (firefox, opera, chromium) +[22:24:49] <mgorny> oh wait, you said binary-only, then opera ;P +[22:24:50] <ulm> creffett: we do: "Binary-only applications must not be installed outside of /opt." +[22:24:56] <ulm> http://devmanual.gentoo.org/general-concepts/filesystem/index.html +[22:24:59] <creffett> ulm: okay, that works +[22:25:23] <creffett> any further discussion on the games topics, or are we ready to vote? +[22:25:31] <wired> I feel games is way too broad a category of packages for one team to enforce things like install location. as long as the package is not doing something stupid, I do not see any reason to enforce stuff on it just because it's a game. +[22:25:38] <ulm> anyway, we can simply say that games should follow our normal rules +[22:25:59] <creffett> yeah +[22:26:41] <Pinkbyte> ulm, +1 from me +[22:26:45] <creffett> vote 1: games team should stop forcing install locations to /usr/games/bin and other odd locations. +[22:27:02] <Pinkbyte> i am for it +[22:27:03] <Tommy[D]> isnt clear to me +[22:27:03] * ulm yes +[22:27:04] * creffett yes +[22:27:14] <creffett> Tommy[D]: would "follow upstream" be better? +[22:27:22] * zlogene yes +[22:27:25] * mgorny yes +[22:27:38] <Tommy[D]> e.g. is that for all packages, for those with group=games and maintainer or only those with games as maintainer? +[22:27:39] <ulm> creffett: "follow upstream and gentoo policies" +[22:27:39] <wired> yes +[22:27:42] <Pinkbyte> creffett, follow upstream, unless it breaks gentoo rules. I mean - if upstream forces installing to /usr/local - screw it +[22:27:45] <creffett> okay +[22:28:11] <creffett> Tommy[D]: the gist of these all is going to be "games team isn't special and should follow the rules the rest of Gentoo follows" +[22:28:17] <ulm> Pinkbyte's wording is better than mine +[22:28:26] <creffett> okay +[22:28:44] <mgorny> does that request them to change the eclass? +[22:28:49] <creffett> mgorny: we're getting there ;) +[22:28:59] <Tommy[D]> creffett: my point is, that imho games team should be allowed to create whatever policy they want for the packages they actually maintain, but others maintaining games themselves should not be forced to follow it +[22:29:05] <wired> I don't mind if some dev feels that a game belongs to a different folder (because of size), we just shouldn't force everyone to do it +[22:29:36] <mgorny> size is rather a poor argument for /usr/games +[22:29:43] <mgorny> esp. that games data goes into /usr/share/games +[22:30:07] <creffett> Tommy[D]: I don't agree, games team should follow the same rules as everyone else +[22:30:43] <Tommy[D]> creffett: games team uses games eclass, kde uses kde eclass, gnome uses gnome eclass.... ;) +[22:31:07] <creffett> Tommy[D]: and gnome and KDE all install to standard locations (given that kdeprefix died a long time ago) +[22:31:16] <mgorny> and we dropped /usr/X11R6 too +[22:32:04] <ulm> another relic from the 1980s :) +[22:32:18] <creffett> heh. +[22:32:22] <mgorny> next meeting we will discuss sbin :> +[22:32:23] * mgorny hides +[22:32:30] <creffett> next vote: kill games group +[22:32:34] * creffett yes +[22:32:51] * zlogene yes +[22:32:53] <Tommy[D]> well, if the vote includes a forced change for packages actively maintained by games team, if it only prevents the games team to force their rules onto others, i am fine with it +[22:33:00] <mgorny> kill games group as used to manage access to running games* +[22:33:08] <creffett> mgorny: what else is it used for? +[22:33:12] <ulm> eh, what about usage of the games group by upstream packages? +[22:33:24] <mgorny> some upstream were using it to share scores... but we broke that by redefining games +[22:33:25] <ulm> like setgid for accessing score files? +[22:33:29] <creffett> ah +[22:33:33] <creffett> I forgot about that +[22:33:38] <mgorny> we will probably need to sed it to another group +[22:33:51] <mgorny> or request people to remove their users from games +[22:34:12] <creffett> what would you suggest? kill games group entirely, or just stop it from being used to restrict game access? +[22:34:25] <ulm> the latter +[22:34:30] <creffett> okay +[22:34:38] * creffett is okay with that +[22:34:42] <ulm> follow usage as it is in other distros +[22:35:55] <creffett> anyone else planning to vote? +[22:36:14] * mgorny yes +[22:36:30] <ulm> what is the vote? "kill games group"? +[22:36:36] * Pinkbyte yes +[22:36:49] <creffett> okay, try this again +[22:37:08] <creffett> vote to stop games group from being used to restrict access to games, it should only be used to follow usage upstream/in other distros +[22:37:15] <creffett> ulm: is that acceptable wording? +[22:37:19] <ulm> yes +[22:37:24] * zlogene yes +[22:37:24] * ulm votes yes +[22:37:42] * creffett yes +[22:37:54] * mgorny yes +[22:38:06] * Pinkbyte yes +[22:38:32] <creffett> wired, Tommy[D] +[22:38:43] <wired> yes +[22:38:55] <Tommy[D]> i abstain +[22:39:00] <creffett> okay, passes +[22:39:25] <creffett> games.eclass: do we want to completely deprecate it, or just vote to confirm that it isn't required +[22:39:46] <mgorny> let's try deprecating. we already voted out all its features :) +[22:39:54] <creffett> k +[22:40:00] * WilliamH is here sorry folks +[22:40:02] <creffett> vote to deprecate games.eclass +[22:40:08] * mgorny yes +[22:40:12] * zlogene yes +[22:40:15] * WilliamH yes +[22:40:15] * creffett yes +[22:40:20] * ulm yes +[22:40:31] * Tommy[D] abstain +[22:40:35] * Pinkbyte abstain +[22:40:59] <wired> abstain +[22:41:23] <creffett> passes +[22:41:26] <Pinkbyte> i'd prefer to make it non-required for generic games ebuild. When it loses most of features - it will be dropped as is, no need to force that on QA level +[22:41:44] * creffett out, can I get a volunteer to run the rest of the meeting? +[22:41:48] <ulm> well, deprecated != removal +[22:41:52] <mgorny> Pinkbyte: right now games.eclass has configurable dirs +[22:42:03] <mgorny> i'm sure some people will try to workaround our decisions +[22:42:21] <Pinkbyte> creffett, sure, i will takeover ;-) +[22:42:31] <creffett> Pinkbyte: okay then, thank you +[22:42:52] <mgorny> good luck, creffett +[22:42:53] <WilliamH> Did I miss the vote on tinfo? +[22:42:56] <Pinkbyte> mgorny, no doubt, i know how behave some of current Games team members +[22:42:57] <zlogene> so, forward to the next item? +[22:42:59] <mgorny> WilliamH: not yet +[22:43:00] <creffett> WilliamH: not yet +[22:43:01] <zlogene> WilliamH, no +[22:43:05] <mgorny> so far killed games +[22:43:25] <Tommy[D]> mgorny: but i liked some games :p +[22:44:05] <mgorny> Pinkbyte: run that meeting! +[22:44:10] * mgorny is hungry +[22:44:16] <Pinkbyte> mgorny, ok then +[22:44:44] <Pinkbyte> next topic: repoman checks for missing slot/subslot operators +[22:44:47] <Tommy[D]> anyway, 10 members, 5 votes, so it did not pass? +[22:44:53] <Pinkbyte> mgorny, your word :-) +[22:45:22] <mgorny> i have mixed feeling about it these days +[22:45:35] <mgorny> but the idea was that repoman is supposed to warn you when you do RDEP+DEP on dev-libs/openssl +[22:45:39] <ulm> Tommy[D]: generally only members being present in a meeting are counted +[22:45:46] <mgorny> and that could match both openssl:0 and openssl:0.9.8 (which has no headers, just libs) +[22:46:14] <Pinkbyte> mgorny, one note. Is that checks would be for RDEPEND only or on DEPEND too? +[22:46:25] <mgorny> so you're required to either do openssl:0, openssl:* explicitly or openssl:= +[22:46:28] <ulm> mgorny: has this been tested in a real world scenario? +[22:46:38] <ulm> the repoman check, I mean +[22:46:39] <mgorny> Pinkbyte: i think ulm has bikeshed it to the point of common subset of RDEP+DEP +[22:46:47] <Tommy[D]> ulm: in previous meetings the idea was to get more then half of the members into the meeting to be able to get a vote accepted, so that is not clear to me +[22:46:49] <mgorny> ulm: i was running it for a while ;P +[22:46:49] <Pinkbyte> let's have some example: boost have subslots. And some app uses ONLY boost headers. Should we force some slot operator here? +[22:47:15] <mgorny> Pinkbyte: if you can really take any slot, you can do :* +[22:47:39] <mgorny> right now slot-less dep on slotted package is treated as semi-undefined behavior +[22:48:05] <Pinkbyte> mgorny, boost have no slots, only subslots. Does that matter? +[22:48:17] <mgorny> that's the second part :) +[22:48:18] <Pinkbyte> ahhh, that's what i want to hear +[22:48:24] <mgorny> first part is just slots in general +[22:48:36] <mgorny> i don't remember who requested subslots anymore +[22:48:51] <mgorny> but the second part is the same for subslots +[22:49:06] <mgorny> i.e. dev-libs/libfoo on subslotted package bad +[22:49:09] <ulm> what's the rationale for the subslot check? +[22:49:18] <mgorny> either :0, :0=, :=, :* to force it +[22:49:35] <mgorny> i.e. to force a specific subslot behavior or to silence the check +[22:49:43] <mgorny> ulm: finding missing subslot uses, i think +[22:50:30] <mgorny> but i'm not really convinced by that, so i put that as second item +[22:51:03] <Tommy[D]> what happens, if a package with only :0 starts to add more slots? +[22:51:18] <ulm> mgorny: it has the potential for false positives, I think +[22:51:47] <mgorny> ulm: yes, it does +[22:52:13] <mgorny> it pretty much requires us to use :* or likes to confirm stuff +[22:52:25] <mgorny> Tommy[D]: with first check? repoman starts issuing warnings about missing slots +[22:52:25] <Pinkbyte> so, let's reiterate. Repoman check for slots is needed for packages, that had no slots, but when they are added - it will ease migration if old ebuilds, depending on that now-slotted package, that will have category/foo:0 instead of category/foo dependency +[22:53:43] <Tommy[D]> mgorny: so maintainer has to request all depending packages to be fixed before adding new slot? +[22:53:58] <mgorny> or when developers are missing the fact that package is slotted, like they do a lot now +[22:54:09] <mgorny> Tommy[D]: basically he has to do all the fixing right now +[22:54:20] <mgorny> we just don't have any checks to help him +[22:57:07] <Pinkbyte> Tommy[D], well, if it would be warning and not error, i do not think that this is problem. And of course, if old behaviour would not be broken until all things would be fixed +[22:57:23] <mgorny> and if it proves to bring too many false positives, we can always revert it +[22:57:37] <Tommy[D]> Pinkbyte: well, if there can be false positives, it cannot be an error ever +[22:58:58] <mgorny> 'false positive' depends on how undefined behavior of lack of slot op is defined +[22:59:01] <ulm> I'd say let's try it for slots +[22:59:15] <mgorny> so let's get it into 3 votes +[22:59:16] <ulm> but not for subslots, at least not immediately +[22:59:22] <mgorny> 1. warning for missing slots +[22:59:29] <mgorny> 2. warning for missing subslots +[22:59:54] <mgorny> 3. recommending :* over no slot for packages that really support all slots and trigger the warning +[22:59:56] <ulm> s/slots/slot operators/ ? +[23:00:11] <mgorny> it can be either a slot spec or slot op +[23:00:14] <Tommy[D]> so the exact suggestion is, that if repoman detects at least 2 versions of the dependency with different slots, that it then issues a warning, if no explicit slot is defined for the dependency? +[23:00:15] <mgorny> i.e. :0 or := or :* +[23:00:26] <mgorny> Tommy[D]: yes +[23:00:58] <mgorny> (or :0/0 or :0=) +[23:01:31] <mgorny> Tommy[D]: i can show you the patch if you want +[23:02:21] <Pinkbyte> can we make this check works only for new revision/version? +[23:02:31] <Tommy[D]> mgorny: thanks, but i am tired and have pretty limited time for now, so probably would not get to checking it :/ +[23:03:01] <mgorny> Pinkbyte: i don't think we have a sane way of figuring that out +[23:03:18] <mgorny> plus, the point is to warn about package deps that used not to be slotted +[23:03:26] <mgorny> this requires retroactive fixes +[23:05:06] <mgorny> did others leave already? :P +[23:05:25] * WilliamH is still here, just reading what's going on... +[23:05:26] <Tommy[D]> maybe already sleeping :) +[23:05:48] <ulm> so, are we going to vote on it, or what? +[23:05:57] <Tommy[D]> i follow the suggestion of ulm: try it for slots only for now +[23:06:26] <Pinkbyte> ok, guys, let's reiterate. Vote 1: should we enable missing slot operator check in repoman? +[23:06:49] <mgorny> sounds right +[23:06:54] * ulm yes +[23:06:55] * zlogene yes +[23:06:58] * mgorny yes +[23:06:59] <Tommy[D]> yes +[23:07:21] * Pinkbyte yes +[23:07:38] * WilliamH abstain +[23:08:13] <Pinkbyte> wired, your voice? +[23:08:28] <wired> abstain +[23:09:18] <Pinkbyte> so, 5 for, 2 abstain, others do not vote? Motion failed, i'd say +[23:09:41] <mgorny> err, what? +[23:09:42] <ulm> 7 members present +[23:09:48] <mgorny> 5 out of 7 is failed/ +[23:09:54] <ulm> so 5 is a majority +[23:10:05] <Pinkbyte> oh, stupid me, counted from total members +[23:10:10] <zlogene> passed +[23:10:14] <ulm> (given that we follow usual rules) +[23:10:17] <Pinkbyte> it's probably too late and my brain is sleeping already +[23:10:35] <Pinkbyte> it's passed of course, no doubt for that, if i would count it correctly :-) +[23:11:03] <Pinkbyte> so, Vote 2: should we enable missing sub-slot operator check in repoman? +[23:11:09] * ulm no +[23:11:11] * Pinkbyte abstain +[23:11:20] <ulm> not for now +[23:11:37] * zlogene abstain +[23:11:42] <Tommy[D]> no (not for now) +[23:11:44] * mgorny nope +[23:11:53] * WilliamH no +[23:12:49] <Pinkbyte> wired, ? +[23:14:51] <Pinkbyte> ok, i figured out that wired's voice did not change situation much in our case. Clear 'no' is said for this check for now, let's move on +[23:15:00] <Pinkbyte> no offense, wired +[23:15:27] <Pinkbyte> next thing: Making global-scope 'use*', 'has_version' and 'best_version' fatal in EAPI 6 +[23:15:51] <ulm> such usage was never allowed +[23:16:03] <Pinkbyte> yeah, devmanual said about that pretty clear +[23:16:04] <mgorny> yet vapier did it +[23:16:14] <ulm> can't we fix remaining usage in tree, and make it fatal everywhere? +[23:16:15] <mgorny> so this is about making it fatal in EAPI 6 +[23:16:39] <mgorny> i don't mind extending it to all EAPIs +[23:16:43] <ulm> it's not related to EAPI 6 +[23:16:51] <WilliamH> one question about this, is this a repoman check? I don't see how a function can know if it was called in global scope. +[23:18:28] <mgorny> no, portage change +[23:18:33] <Pinkbyte> WilliamH, i suppose it would be portage and not repoman check +[23:18:35] <mgorny> the global call will cause 'die' +[23:18:37] <Pinkbyte> ahh, i was right :-) +[23:19:17] <ulm> mgorny: one has to make sure that it doesn't die when uninstalling a package +[23:19:43] <mgorny> ulm: then EAPI 6 ;) +[23:19:49] <Pinkbyte> retroactive changes are bad, BUT, we will do retroactive change to set up behaviour that was intended by standart and devmanual... +[23:20:04] <Pinkbyte> ulm, hm, i forgot about this case, thanks for catching this up +[23:20:11] <ulm> mgorny: so it _does_ die on uninstall? +[23:20:36] <mgorny> ulm: not sure +[23:20:37] <wired> Pinkbyte: no problem, I'm at work so 'abstain' is my default answer if not here +[23:20:48] <mgorny> i don't think portage actaulyly reevals globals on uninstall +[23:20:48] <Pinkbyte> ulm, it would be hard to check, i think, so probably would be better to not alter behaviour for already installed ebuilds +[23:21:26] <ulm> mgorny: it should source the environment file from the VDB but not the ebuild (?) +[23:22:06] <mgorny> yes, i think so +[23:22:12] <WilliamH> I think it is going to be hard to check inside a function whether it was called from global scope or not. +[23:22:30] <mgorny> WilliamH: it's already implemented +[23:22:37] <mgorny> and enabled for Arfrever's EAPIs +[23:22:48] <mgorny> pretty much we can check whether we're in a phase +[23:23:12] <WilliamH> mgorny: Oh ok. +[23:23:26] <ulm> can we shelve this till next meeting please? I don't have enough input to be ready for a vote +[23:23:59] <WilliamH> That's fine with me. +[23:24:17] <mgorny> if you feel like it +[23:24:34] <mgorny> next item important +[23:24:35] <Pinkbyte> guys, should we? I think if we vote for that change in EAPI 6 it would not hurt anyone. Setting this for all previous EAPIs is another thing... +[23:24:49] <ulm> or that +[23:25:10] <ulm> but it won't go into pms +[23:25:29] <mgorny> it already is in pMS :) +[23:25:33] <ulm> or rather, it is in pms already, for all eapis :) +[23:25:48] <Pinkbyte> ulm, huh? i thought it is already for all EAPIs, but we just do not do such check in reality +[23:25:58] <ulm> Pinkbyte: exactly +[23:28:14] <Pinkbyte> So, will talk about current EAPIs when we will have clear understanding about all possibly consequences Vote: Making global-scope 'use*', 'has_version' and 'best_version' fatal since EAPI 6 +[23:30:02] * Pinkbyte yes +[23:30:04] * mgorny yes +[23:30:12] * ulm yes +[23:30:29] * Tommy[D] yes +[23:31:08] * WilliamH yes +[23:31:20] * uDH ушел (Ping timeout: 256 seconds) +[23:31:35] * zlogene yes +[23:32:18] <Pinkbyte> 6 'yes', motion passed +[23:32:37] <Pinkbyte> Next topic: Use of <maintainer/> and <herd/> elements in metadata.xml +[23:32:48] <mgorny> yay +[23:32:54] <mgorny> so my newest idea +[23:32:59] * WilliamH thinks <herd> should just be switched to <maintainer> +[23:33:01] <Pinkbyte> a bit ambiguous topic as it recorded +[23:33:03] <mgorny> 1. replace <herd> with <maintainer>/<email> +[23:33:12] <mgorny> 2. possibly add maintainer type="foo" +[23:33:33] <Tommy[D]> i am leaving now, i really need to get some sleep +[23:33:50] <mgorny> the goal is to make bug assignment simpler +[23:34:10] <mgorny> we keep maintainer/email useful for bug assignment, add extra information without changing the spec +[23:34:12] <ulm> I must leave soon, too +[23:34:29] <WilliamH> mgorny: right now, you 1) assign to first maintainer, 2) cc everyone else. +[23:34:31] <zlogene> herd != maintainer IMO +[23:34:52] <zlogene> why should we do so then +[23:34:57] <WilliamH> zlogene: technically, you are right, a herd is a group of packages... +[23:35:04] <Pinkbyte> zlogene, basically it is. i mean, herd acts like alias for group of maintainters in terms of bug wrangling +[23:35:15] <ulm> is this topic even a qa issue? +[23:35:20] <Pinkbyte> but we should differ herd and herd maintainers of course +[23:35:28] <ulm> it's something for the -dev ml +[23:35:29] <WilliamH> herds are dead +[23:35:50] <zlogene> ulm, the same question here +[23:35:55] <Pinkbyte> WilliamH, lack of cooperation != dead +[23:36:04] <Pinkbyte> WilliamH, yes, there is really dead herds +[23:36:13] <WilliamH> Pinkbyte: relevence == dead +[23:36:27] <WilliamH> Pinkbyte: the herd concept is pretty useless +[23:36:30] <mgorny> we can leave herds, just change the tags used to assign bugs +[23:36:34] <zlogene> Pinkbyte, there are, i'd even said :D +[23:37:02] <mgorny> i.e. <herd>foo</herd> -> <maintainer type="herd"><email>foo-bugs@gentoo.org</></> +[23:37:27] <Pinkbyte> WilliamH, it works for quite a long time as i know. Do you propose to drop the whole idea of collective maintainership? +[23:38:17] <WilliamH> Pinkbyte: this is part of the problem. Herds are NOT people, they are groups of packages. +[23:38:34] <WilliamH> Pinkbyte: people maintain herds, they are not in herds. +[23:38:45] <Pinkbyte> WilliamH, but herd maintainers ARE a group of people. So mgorny change seems reasonable in this case +[23:39:27] <Pinkbyte> for me it's quite simple. Project maintains some complicated stuff. That stuff are present as one or multiple group of packages(herds). Herds are maintained by respective maintainers +[23:39:42] <Pinkbyte> first problem - herds without a project +[23:39:44] <WilliamH> Pinkbyte: but why not just have aliases for the herds e.g. <maintainer><name>group name</name><elail>foo@gentoo.org</email></maintainer> +[23:40:03] <WilliamH> Pinkbyte: it is just another maintainer. +[23:40:06] <ulm> http://www.gentoo.org/proj/en/council/meeting-logs/20141111-summary.txt +[23:40:19] <ulm> council has shelved this in the last meeting +[23:40:36] <ulm> so does it make sense if we decide something here now? +[23:41:09] <mgorny> we could give a recommendation to the council +[23:41:31] <zlogene> ulm, yes it does, for the future references +[23:42:27] <Pinkbyte> mgorny, i like your idea about 'type' attribute in maintainer field, but i think we can go just by converting herds to apropriate maintainer tags without additional attribute +[23:42:45] * WilliamH agrees with Pinkbyte +[23:42:45] <Pinkbyte> anyway, i saw some packages that has <maintainer>media-video@gentoo.org</maintainer> and no herd at all +[23:42:49] <mgorny> there were concerns that we lose information +[23:43:05] <WilliamH> mgorny: what information? I don't see any information loss. +[23:43:18] <mgorny> but basically, i'm all for having some other structure mapping e-mail addresses to herds +[23:43:50] <ulm> we need to distinguish single maintainers from projects +[23:44:07] <mrueg> how about media-video@projects.gentoo.org ? +[23:44:09] <ulm> or whatever will substitute herds +[23:44:17] <WilliamH> ulm: does that really matter though? +[23:44:31] <WilliamH> ulm: you can do that in the <name> tag of a maintainer +[23:44:51] <Pinkbyte> WilliamH, good catch! +[23:45:26] <ulm> WilliamH: how to you prevent projects from using the name tag? +[23:45:40] <ulm> s/to/do/ +[23:46:12] <WilliamH> ulm: you don't. <maintainer><name>foo project</name><email>foo@gentoo.org</email></maintainer> +[23:46:44] <ulm> the dtd says that names are only for individuals, though +[23:47:09] <ulm> but it has to be changed anyway +[23:47:38] <Pinkbyte> ulm, could you raise mgorny's idea on next Council meeting? If yes, i think we can skip voting on this entirely, until they spoke their word +[23:47:55] <ulm> yeah, can do +[23:48:24] <WilliamH> sounds good to me +[23:48:35] <Pinkbyte> good. Next one: ncurses[tinfo] flag used to change library ABI, bug #487844 +[23:48:38] <willikins> Pinkbyte: https://bugs.gentoo.org/487844 "sys-libs/ncurses: USE=tinfo changes library ABI"; Gentoo Linux, Applications; RESO, WONT; mgorny:base-system +[23:48:52] <Pinkbyte> i suppose, that's here because of WilliamH +[23:49:42] <Pinkbyte> my personal opinion - vapier said all things right in the bug. Extra revdep-rebuild ewarn is not needed in this case +[23:49:43] <ulm> I don't see any breakage there, unless users switch from -tinfo to +tinfo and then back to -tinfo +[23:50:04] <mgorny> this doesn't go alongwith our work on subslots +[23:50:09] <Pinkbyte> ulm, in the latter case - there would be preserved rebuild warning +[23:50:17] <mgorny> we want to know ABI breakages before upgrading +[23:50:24] <ulm> it's certainly not ideal, but we don't have use dependency operators +[23:50:30] * WilliamH is against dropping the use flag +[23:50:40] <mgorny> not allow people to play with them because base-sysetm can't handle deciding +[23:50:53] <mgorny> i'm for making it use.masked or use.forced +[23:51:02] <WilliamH> There is no prohibition against using a use flag that way +[23:51:05] <mgorny> or droppping entirely, and doing the switch via revbump with subslot change +[23:52:16] <WilliamH> I posted a patch on the bug that could be used to provide a warning to the user if we really want to do that. +[23:52:45] <WilliamH> We can't force dropping or masking of the use flag. +[23:53:06] <WilliamH> But there is a way as shown in that patch to test whether it was turned off. +[23:53:44] <ulm> one could also say that the real issue is with reverse dependencies, that are sniffing if there's a tinfo lib and automagically depend on it +[23:54:04] <Pinkbyte> mgorny, we can not go on subslot logic in all times of ABI problems happened. revdep-rebuild is supported solution, so i do not see serious QA issue here(yet) +[23:54:11] * zlogene is out, because has no sleep for 2 days +[23:54:12] <mgorny> ulm: that's how upstream wants it +[23:54:16] <mgorny> tinfo is basically the future way +[23:54:27] <mgorny> normal distros just switch and fix the deps +[23:54:33] <Pinkbyte> mgorny, but too many breakages happens for now +[23:54:42] <mgorny> only gentoo makes a lot of noise and doesn't do real work +[23:55:35] <Pinkbyte> mgorny, you can go in usual way - fix all bugs about USE="tinfo" enabled libncurses consumers and then say - 'hey guys, nobody uses ncurses without libtinfo, let's move on!!!' +[23:55:41] <ulm> well, add WilliamH's patch then, and warn if the users switches from USE=tinfo to USE=-tinfo +[23:55:48] <Pinkbyte> mgorny, if you are really THAT care +[23:55:49] <ulm> that certainly won't harm +[23:57:51] <WilliamH> I can do it if you want after we are done +[23:57:55] <WilliamH> ulm: ^^ +[23:58:03] <WilliamH> I can add the patch. +[23:58:37] <ulm> has vapier commented on it? +[23:58:42] <WilliamH> no +[23:59:15] <ulm> WilliamH: hm, you could emit the warning in pkg_preinst +[23:59:25] <WilliamH> I would need to know the exact revdep-rebuild command users should use though. +[23:59:27] <ulm> would get rid of the environment saving +[00:00:04] <WilliamH> ulm: Hmm, what would the test look like if I did that? +[00:00:15] <mgorny> pkg_pretend maybe/ +[00:00:31] <WilliamH> has_version [tinfo] && ! use tinfo +[00:01:04] <ulm> WilliamH: I think so +[00:01:36] <ulm> and revdep-rebuild --library=/path/to/libtinfo.so +[00:03:11] <WilliamH> ulm: I guess that path would end up being ${EROOT}usr/lib/libtinfo.so +[00:03:58] <Pinkbyte> WilliamH, yep +[00:03:59] <ulm> or $(get_libdir) instead of lib +[00:04:09] <WilliamH> ulm: right. +[00:04:12] <Pinkbyte> ah, nice catch too +[00:04:33] <Pinkbyte> errr, nope +[00:04:39] <WilliamH> I'll update the bug first. +[00:04:44] <ulm> no? +[00:04:44] <Pinkbyte> i have it in /lib64/libncurses.so.5 +[00:04:56] <Pinkbyte> so i suppose no /usr thingie for libtinfo too +[00:05:03] <Pinkbyte> but it should be checked, of course +[00:05:58] <ulm> Matched Files: /usr/lib64/libtinfo.so; /usr/lib32/libtinfo.so; /usr/lib/libtinfo.so +[00:06:02] <ulm> says e-file +[00:06:41] <ulm> and it makes sense because terminfo stuff is in /usr/share +[00:06:49] <Pinkbyte> ulm, portagefilelist.de agrees too +[00:07:10] <Pinkbyte> so, i was wrong +[00:07:12] <ulm> that's the same as e-file, I think +[00:09:25] <ulm> sorry, but I must leave now +[00:09:27] <Pinkbyte> ok, guys. I have a bit tired too, so can we skip last part of agenda - status checks about GTK use flag issue, missing QA meetings summary and other stuff. I know that this is important, but as i see - not much of us are left in channel +[00:09:33] <Pinkbyte> ? +[00:09:48] <ulm> yeah, please postpone +[00:10:14] <Pinkbyte> WilliamH, ^^ ok with that? +[00:10:42] <Pinkbyte> mgorny, wired, ^^ +[00:10:47] <mgorny> sure +[00:10:53] <WilliamH> That's fine. +[00:11:01] <wired> sure +[00:11:08] <WilliamH> So for now should I just update the bug? +[00:12:20] <Pinkbyte> WilliamH, path that you are supposed(${EROOT}usr/lib/libtinfo.so) is correct. Add warning about needed revdep-rebuild for library in that path +[00:12:30] <Pinkbyte> i think that's all that we can do now +[00:12:56] <WilliamH> Pinkbyte: ok +[00:14:17] <Pinkbyte> All right guys, meeting is over. Thanks to everyone +[00:14:37] <WilliamH> ulm: I think there is a concern about using preinst to emit the warning... +[00:14:40] <Pinkbyte> Will try to post meeting log and summaries tomorrow. If i do not, just poke me with friendly reminder |