Timestamps are in UTC+3 [22:04:05] Let's start then, maybe others will join us later [22:04:16] WilliamH, ^ [22:04:32] I saw he around [22:04:49] First of all - the simpliest thing. Give mrueg a warm welcome as our fellow team member. And kudos to zlogene as Deputy Lead [22:04:56] * WilliamH is here [22:05:02] * wired here [22:05:18] mrueg: welcome :) [22:05:30] mrueg: Welcome aboard. :-) [22:05:44] thanks :-) [22:06:19] * mgorny kicked mrueg from #gentoo-qa (welcome) [22:06:36] oh wait, is that a wrong practice? :D [22:06:40] meh [22:06:54] well, it's usual for generic newcomers, so... not sure :-) [22:06:54] heh [22:07:01] too late :P [22:07:11] he's a dev long enough to have autorejoin [22:07:13] * mrueg (~mrueg@gentoo/developer/mrueg) joined #gentoo-qa [22:07:48] mrueg: welcome [22:08:11] :) [22:09:23] so, i will take care about our logs, but it would be nice to have a backup. zlogene, could you please enable logging in your client too, just in case? [22:09:45] Pinkbyte, sure [22:12:21] So, let's begin our business [22:12:43] games policies... again. Or should i say - at last? :-) [22:13:24] bug #537580... [22:13:27] Pinkbyte: https://bugs.gentoo.org/537580 "Allow packages to install files in games directories without chgrp games"; Gentoo Linux, Games; CONF; ulm:qa [22:13:54] I've outlined the problems and proposed a solution in comment #0 [22:14:16] i do not want to be rude, but i am kinda tired about hasufell's nagging, who are not willing to put any reasonable amount of real work in this issue, but continues saying that all proposed stuff are useless [22:14:49] i like ulm's solution [22:15:00] basically, devs still cannot install any games in FHS locations, because games.eclass sets the dirs' permissions to 750 [22:15:01] Pinkbyte: hasufell is a true troll, we could ban him and he wouldn't care much [22:15:09] as in, he does that on purpose [22:15:23] but it's comrel, not qa business :) [22:15:52] i'd vote for ulm's solution [22:15:54] so my first suggestion would be to change all top-level games dirs to root:root and 755 (i.e. the default) [22:16:02] mgorny, true. I am just saying about my personal attitude. Now, technically... [22:16:11] patch for games.eclass is attached to the bug [22:16:16] ulm, let me clarify - do you propose to change games.eclass? [22:16:18] ulm: that is equal to /usr/bin and others, correct? [22:16:39] ulm, sorry, did not see your attachment in bug, ignore last question [22:16:43] Pinkbyte: yes, just the part that restricts the dirs listed in comment #0 [22:17:13] e.g. /usr/games and /var/games should be world readable [22:17:30] ulm, no objections from me [22:17:36] * WilliamH is reading [22:17:41] any more restrictive permissions can be applied to files or subdirs [22:18:18] second part is a new group for shared scores/bones/states [22:18:45] the "games" group cannot be used for that, unfortunately [22:18:54] so we would need a new name [22:19:16] like "scores" [22:19:36] ulm, 'gamescores'(or scores) seems more valid for me, rather than proposed name 'gamers' in maillist [22:19:51] i'd go for scores [22:19:54] simple and efficient [22:19:56] or "spiele", "jeux", "juegos", "ludi", "gry" [22:19:59] gamescores [22:20:18] Pinkbyte, mrueg: this makes me think about 'cores' [22:20:26] mrueg: yeah, but it's too long [22:20:45] or maybe game-stats [22:20:49] shouldn't be more than 8 chars otherwise some programs cannot display it [22:20:58] gamestat ;) [22:21:00] and no hyphen ;) [22:21:15] gscores? ;D [22:21:19] ulm, lol, a bit off-topic: your last sentence reminds me about some russian user, that was really curious about why locale defined in make.conf as LINGUAS and not LANGS for example :-) [22:22:03] * WilliamH isunsure what the games group is supposed to be used for [22:22:22] Pinkbyte, lingua latina non ... you know [22:22:26] WilliamH: games would be setgid "scores" (or whatever its name will be) [22:22:41] so they can access shared score files on the system [22:23:03] ulm: My question though was, why not setgid games? [22:23:09] WilliamH, 'games' can not be thrown away because of backward compatibility. And can not be utilized by regular users because of security bug #125902 [22:23:13] Pinkbyte: https://bugs.gentoo.org/125902 "games-roguelike/nethack: local privilege escalation and insecure savegame creation (CVE-2006-1390)"; Gentoo Security, Vulnerabilities; IN_P; taviso:security [22:23:48] WilliamH: many gentoo users will be in the games group, so there will be a security issue if we have setgid binaries at the same time [22:23:59] WilliamH: long story short, because that group needs to be empty ;) [22:24:01] WilliamH, if regular user can overwrite score files in default configuration by another app, not related to reading/writing them(like text editor) it creates some nasty security holes [22:24:32] So users shouldn't have been put in the games group to begin with. [22:24:54] WilliamH: right, but too late to change that now [22:24:56] WilliamH, yes, but we can not say them - go away from games group until we throw away games.eclass entirely [22:25:13] WilliamH, it will not happen in any near future, it will require some work to do [22:25:39] Pinkbyte: ok, thanks. :-) [22:25:51] and that bitrotting security issue pains me from the time i join Gentoo Security, i am glad that it was brought to our attention(at last!) [22:26:03] so, gscores, gamestat, or should I go to the -dev ml for bikeshedding? [22:26:06] or launch a forums poll? :) [22:26:36] gamestat ++ [22:26:37] whatever you want man, I think this is not so important we need a vote [22:26:40] gamestat, fine [22:26:42] ulm, i like 'gamestat' [22:27:00] ok, gamestat it will be [22:27:17] can we have a vote on the whole proposal [22:27:19] ? [22:27:45] as outlined in bug 537580 comment #0 [22:27:47] https://bugs.gentoo.org/537580#c0 "Allow packages to install files in games directories without chgrp games"; Gentoo Linux, Games; CONF; ulm:qa [22:27:51] (first two items) [22:28:16] Let's clarify: "Create separate group: 'gamestat' and set score files to it, /usr/games and /var/games should be world-readable" [22:28:32] well, all dirs listed in the bug [22:28:57] /usr/games /usr/games/bin /usr/games/lib* /usr/share/games /var/games /etc/games /opt [22:29:32] /opt was already fixed, though [22:30:50] and these dirs' permissions and owner should just be left alone [22:30:56] root:root and 755 [22:31:21] like /usr/bin and all others [22:31:32] * WilliamH yes [22:31:36] * Pinkbyte yes [22:31:38] * mgorny yes [22:31:39] * ulm yes [22:31:53] * zlogene yes [22:31:56] yes [22:32:35] mrueg, ? [22:32:42] yes. [22:32:59] thank you :) [22:33:08] motion passed [22:33:25] * wired yes [22:33:50] ...unanimously [22:33:51] :-) [22:34:18] so, next question... "Developers ignoring (not updating) eclass/ChangeLog file" [22:34:46] Pinkbyte, what do you mean by this item ? [22:34:46] * WilliamH doesn't have a strong opinion since once we go to git it will be irrelivent. [22:34:51] we should get a consistent policy here [22:34:51] Who brought this up? [22:34:56] * mgorny did [22:35:04] long story short, some devs update eclass/ChangeLog, some don't [22:35:08] Changelogs should be updated [22:35:11] zlogene, i am just reading what is in our agenda, not all of those items are brought there by me [22:35:13] repoman should work on profiles/ and eclass/ [22:35:13] the result is you can't read the file reliably [22:35:23] right now it doesn't [22:35:44] mrueg, repoman is for qa checks [22:35:46] mrueg, the problem is that not every directory in profiles/ has ChangeLog [22:36:01] echangelog can deal with profiles and eclass [22:36:04] Pinkbyte: that's not really a problem, it's a bit irritating [22:36:09] some deep arch profiles have only top level ChangeLog(and it's fine if it is consistent) [22:36:20] as long as we have a ChangeLog in eclass it should be updated [22:36:30] zlogene: repoman ci -m "Foo" calls echangelog, except for eclass or profile. [22:36:31] mgorny, i mean that this is problem for a automatic tool to check, such as repoman [22:36:49] the problem is that it's not devs forgetting, i think [22:36:54] mrueg, i know [22:37:01] they openly refuse to update the ChangeLog [22:37:24] so we should decide if refusing this is a reason for QA action [22:37:26] mgorny: Yes, there is some of that going on too. [22:37:35] or we should just drop the ChangeLog since it confuses people [22:37:39] mgorny: But I've also seen situations where [22:37:52] well don't we try to enforce the usage of repoman to commit stuff to the tree? [22:37:53] mgorny: repoman ci -m 'msg' doesn't work. [22:38:28] mgorny: I can't figure out when it doesn't work. [22:38:42] for all I care we can drop the Changelog files entirely and rely on cvs log for eclasses, but it should be consistent [22:38:57] mgorny, well, before we will have git we should preserve as much ChangeLogs as possible [22:39:31] * WilliamH agrees with Zero_Chaos about consistency [22:39:51] bug #390651 [22:39:53] mrueg: https://bugs.gentoo.org/390651 "repoman: support commit in non-package directories like eclasses and profiles"; Portage Development, Repoman; CONF; zmedico:dev-portage [22:39:58] we could rely on CVS commit messages, but they are not for end-users as i would said. 'git log' is a more user-friendly [22:40:21] Pinkbyte: git log and cvs log are effectively the same thing. you just have to |less on your own for cvs [22:40:50] this changelog problem has been around forever, I don't see it going away until we switch to git [22:40:55] i'd suggest two possible decisions: [22:41:04] mgorny, phrase "we will have a git" correlates to HL3 release [22:41:26] a. we declare that if a particular subtree or a parent tree has a ChangeLog, developer must update it when committing to it [22:41:37] zlogene, be more optimistic. At least mgorny do a real work for this, writing nice kind-of-migration software [22:41:49] b. we drop eclass/ChangeLog and possible others ChangeLogs used inconsistently [22:41:59] I believe that a. is existing policy already [22:42:12] mgorny, "a" plan is fine by me [22:42:20] ulm, not sure [22:42:24] "a" allows "b" even. [22:42:39] Because if the changelog is gone you don't have to worry about it. [22:43:00] maybe developers confused since they don't know what changelog they should update? [22:43:02] ulm: if it is, then we should confirm it [22:43:13] ulm, i was wrong - http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html [22:43:15] in subprofiles case [22:43:16] zlogene: no, i'm talking about eclass/, there's only one ;P [22:43:21] "Note: If a ChangeLog file is not present in your current working directory, then you should write a ChangeLog entry in the parent's directory ChangeLog file. " [22:43:24] ah [22:43:43] so, it IS a policy, from devmanual [22:44:50] and i do not think that we need to change it in current situation. It's in pure "a" variant, suggested by mgorny [22:45:28] * mgorny prepares a gentoo-dev@ mail then :) [22:45:47] we could confirm the policy again [22:46:09] I say we officially confirm the policy [22:46:12] maybe ping portage-devs to add support to repoman for these profiles? [22:46:25] s/profiles/Changelog generation/ [22:46:35] mrueg: not sure if you can do that reliably [22:46:50] it would have to somehow distinguish between 'update parent changelog' and 'create new changelog here' [22:46:56] mrueg: I'm not sure how much work we should ask the portage devs to do, because [22:47:10] mrueg: once we change to git, the ChangeLog files will be gone [22:47:27] mgorny, dol-sen is quite responsive and not so busy as zmedico(which is responsive too). And that's not so hard work to do [22:47:29] mgorny: well at least for eclass it should be easy? [22:47:47] mrueg: per council decision [22:47:48] yes [22:48:01] WilliamH, if we will pospone fixing this until git migration is done it will be there -> not good [22:48:48] Pinkbyte: I'm just saying that any fix we do should be a fix that won't break again once the git migration happens. [22:49:07] Pinkbyte: and the ChangeLog disappears [22:49:08] WilliamH, repoman does not write to changelog in git repos, IIRC [22:49:11] can we vote on confirming this policy then? if we remove all the ChangeLogs with git, the rule would still be fine [22:49:15] git migration will change things, it is what it is. [22:49:27] ack mgorny [22:49:34] ack mgorny [22:49:42] * ulm votes yes for confirming the policy [22:49:57] * WilliamH yes [22:49:58] And yes, let's not mix things up. We are with cvs now - so, let's keep things clear and tidy NOW [22:49:58] (which means vote yes) [22:49:59] yes [22:50:04] * Pinkbyte yes [22:50:12] * zlogene yes [22:50:21] * mgorny yes [22:50:27] so we all seem to agree, what do we do about violators? revert their changes? [22:50:49] publicly insult their mothers? [22:50:54] that would be an overreaction :) [22:50:59] both :) [22:51:20] flaming bags of dog poop on their porch? [22:51:24] Zero_Chaos, send apropriate message in gentoo-dev, blaming author and asking to update changelog itself [22:51:38] we can't have a policy we don't enforce, so we need to have a policy for enforcement. [22:51:49] I'm fine with emailing the dev directly and cc gentoo-dev [22:51:50] Zero_Chaos, you are really inventor these days, are not you? :-) [22:51:54] but not all devs read gentoo-dev alone [22:52:03] * WilliamH agrees with Pinkbyte [22:52:16] That would be a response to a msg on gentoo-commits probably [22:52:21] Zero_Chaos, do we have any other method? [22:52:24] Zero_Chaos, sure, direct mails WITH CC-ing gentoo-dev@ is fine too [22:52:28] g-dev only [22:52:37] + CC qa@ [22:52:47] yeah [22:52:52] zlogene: if we don't email the dev directly, they might not see it. I'm a few thousand behind on gentoo-dev [22:52:52] i'd say gentoo-dev + 24h timeout [22:52:58] if developer doesn't update the ChangeLog, we revert [22:53:26] WilliamH, i am not receiving all mail from gentoo-commits and it's not trivial to receive a specific e-mail from mailman archive too, so, it depends... [22:53:26] and a regular QA action on repeated offenses [22:53:30] g-dev alone isn't good enough though because g-dev is not mandatory for devs. [22:53:38] mgorny: we need a lcvs-qa-revert tool ;p [22:53:45] mgorny: revert because of missing changelog entry? what if it's an important fix? [22:54:05] I think email warnings and we don't bind our hands if we have a repeat offender [22:54:20] Yeah, we would have to use common sense; we can't just revert depending on the fix. [22:54:38] maybe [22:54:38] ulm, i'd say write a message before rever (directly to dev maybe) [22:54:45] *revert [22:55:00] but not reverting means the ChangeLog will again be inconsistent [22:55:03] ulm, agreed, retroactively add ChangeLog entry is better than losing a critical fix. But it should not be a usual practice like 'ah, those guys will update changelog themselves" [22:55:08] wait. revert changes because of changelog? [22:55:29] may be we should make a template for it? [22:55:38] I don't think we need to officially state we will revert changes. i think we can leave ourselves free to act as appropriate [22:55:44] mgorny: if we revert it, we need to fix the changelog anyway right? [22:55:49] please don't, it may be a policy violation, but the commit may be more important than the policy violation. [22:55:59] wired, ++ [22:56:02] aka echangelog "Foo"; echangelog "Revert foo" [22:56:08] * WilliamH is against specifying how we will react [22:56:32] That should be a case by case kind of thing. [22:56:41] mrueg: well, if you revert something that wasn't there, you don't say you did :) [22:56:50] the only real solution is to enforce this server side. until then, we have to point fingers and accept that some people will not follow rules unless they are enforced [22:57:43] wired, and again - ++ from my side [22:58:14] apropriate git hooks will screw such retarded behaviour and force dev's commits to be nice and shiny [22:58:22] ^^ [22:58:23] mgorny: so you even don't echangelog "Revert foo"? [22:58:23] **devs' [22:58:25] Folks, you cannot just blindly revert an update because of a ChangeLog entry missing. [22:58:43] mrueg: yes [22:58:44] we cannot blindly revert fixes, period. [22:58:47] WilliamH: ++ [22:58:57] and we're spending way too much time on this, it's not an important policy altogether [22:58:58] how about reverting unreviewed eclass changes? [22:59:10] so let's vote that we email the developer, cc -dev, and deal with anyone who refuses as appropriate [22:59:22] mgorny: again, no. [22:59:24] so, let's recap: "Remind all about our policy on ChangeLog files" [22:59:26] mgorny: not all eclasses require a review [22:59:38] e.g. toolchain.eclass doesn't [22:59:40] mgorny, i am understanding where this goes. That's ANOTHER issue [22:59:49] ulm, hm. Why? [23:00:00] Pinkbyte: the devmanual says so [23:00:13] mgorny: that's a different issue altogether, I'd like to see us use a review tool and enforce at least one peer review, starting with eclasses, but that's something for another day :P [23:00:15] and explicitly mentions toolchain as example [23:00:52] * WilliamH is with Pinkbyte remind everyone about our policy [23:01:14] ulm, you were right, again [23:01:21] Then handle violaters on a case by case basis [23:01:28] "It is not usually necessary to email the gentoo-dev list before making changes to a non-general eclass which you maintain. Use common sense here." [23:01:29] just like any other violation [23:01:39] !herd toolchain [23:01:41] Pinkbyte: (toolchain) halcy0n, kumba, lu_zero, rhill, vapier [23:02:11] vapier is there, so it's his right to do so and accept all consequences of breakages [23:02:50] but while at it, do we consider it ok to revert if the commit actually causes breakage, and request fixing it first? [23:03:21] mgorny, yes, but WITH notifying those who break it about breakage [23:03:22] I would revert if the commit wrecked havoc [23:03:49] and ping the proper people to fix it [23:04:00] mgorny, even after reverting, does not matter. Our own policy requires that for serious breakages - to send notice to the actual maintainer that things was bad and WE fixed it [23:04:02] we really need a review tool ^_^ [23:04:50] should go without saying that the maintainer will be notified [23:05:33] ulm, by sending notice i mean e-mail, that does not require it's ACK [23:05:40] just a reminder [23:05:50] that things reverted on purpose [23:06:08] ok, i guess we can move forward with the agenda [23:07:04] yep, we voted for the initial agenda proposal, motion passed [23:07:19] "Missing QA meetings summaries" [23:07:38] Not sure what i personally can do here. Probably nothing, unless somebody has missing logs [23:09:00] which ones are missing? [23:09:37] * zlogene has no logs [23:09:44] * WilliamH has no logs [23:10:26] Zero_Chaos, oh, stupid me, i thought that logs are missing too! [23:10:36] I also have no logs [23:10:41] so, we just need to provide a convinient summary for them [23:10:45] we can ask robbat2 [23:10:55] willikins is logging IIRC [23:11:01] no need - we have all meeting logs on our wiki page [23:11:29] just lacks some summaries for March 19, 2014 and March 26, 2014 meetings [23:11:51] i will take care of that and post apropriate summaries [23:11:58] Pinkbyte: thanks [23:13:31] "GTK use flag" status check [23:13:55] Who wants to discuss this? Your word. [23:14:03] If anyone ever needs logs, feel free to ask me for any channel I am in. [23:14:12] quassel logs everything. [23:15:19] gtk use flags? again? [23:15:50] Pinkbyte: has the status changed? [23:16:00] heh, I sent an email to the gnome team sometime back but we never got an answer. [23:16:01] if not: unchanged. ;) [23:16:29] So I would say the status is unchanged. [23:16:49] so how do we proceed? [23:17:01] kill everyone in the gnome team! [23:17:02] we cannot wait for the gnome team forever [23:17:23] that or just do it, assuming someone cares enough to do the work [23:17:23] Zero_Chaos: you have crative suggestions today :) [23:17:28] *creative [23:17:40] Zero_Chaos, do you have a pistol for this purpose? [23:17:41] ulm: I'm working on something I find enjoyable, it helps my mood a lot. [23:17:47] zlogene: several [23:17:52] * WilliamH doesn't know enough about the build system, or gtk in general to comment. [23:18:01] well, i remember WilliamH's e-mail. I propose to send it again. And then - if no answer will be till the next meeting - move that to Council. There is nothing we can do when we are ignored [23:18:04] e.g. does upstream support gtk slotting? [23:18:36] WilliamH, not really matters in case of regular apps, that usually build with only ONE of GTK versions, but can not be built with both [23:18:48] i mean - simultaneously build with both [23:19:04] ahh, my favorite QA issue. [23:19:05] * creffett here [23:19:11] creffett, o/ [23:19:34] creffett, \o [23:19:41] * WilliamH would have to go back and dig up the email. [23:19:55] creffett: \o/ [23:20:43] WilliamH: does it matter? they've been asked several times and ignored the requests [23:21:32] creffett: good point. [23:22:14] is this crusade worth fighting? [23:22:22] ulm, are you ok with moving that up to Council? [23:22:30] if none of us is willing to make the commits, then we should drop this [23:22:34] mgorny, consistency and following policies? Yeah, why not ;-) [23:22:37] that's the only way it will ever get done [23:22:41] Pinkbyte: fine with me [23:23:50] Zero_Chaos, i can dig with this, if i will have strong backup on my shoulders. Saying "I am QA team lead and we decided this should be THAT way" is not enough here [23:24:17] Pinkbyte: it really is. You will only ever have the power you assume. If you assume you are weak, then you are. [23:25:04] Pinkbyte: qa has a lot of tree-wide authority. It is up to us to figure out how to use it. [23:26:10] Pinkbyte: the only way someone can override qa is by going to the council. [23:26:29] No doubt it is. But ulm already agrees to bring that to Council, so we would not blamed to over-use our powers. In any case, this is consistency issue, and it is serious. But nothing is broken badly on users systems [23:26:44] We have no authority if we choose not to exercise authority. We have authority to do this, if we choose to. [23:27:10] but again, this will never happen if we don't do the work [23:27:55] It is a consistency issue that I personally think we should follow through on. [23:28:04] Pinkbyte: alternatively to forwarding this to the council, you could post the qa decision on gtk and gtk3 flags to the -dev ml [23:28:09] is that a volunteer I hear? [23:28:13] I"m not really ina position where I can do the commits personally since I don't use a gui [23:28:45] Pinkbyte: assuming that we have a decision. do we? [23:28:51] ulm: that will end up in endless arguments again [23:29:17] WilliamH, we have answer from eva@, but it's only about 'keeping us in touch' with changes he planned to do [23:29:22] ulm, yes [23:29:25] ulm: I thought we did have a decision... but I don't remember now. [23:29:29] WilliamH: if it's a policy it has to be made public [23:29:42] makes no sense, otherwise [23:30:32] we had a discussion with the conclusion that we want gtk=GTK2 and gtk3=GTK3 [23:30:45] but I don't remember if we had a formal vote on it [23:31:22] ulm, https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#GTK_flag_situation [23:31:23] we do [23:32:10] The email I sent was to ask the gnome team for more information about why they are doing things differently, but they never answered. [23:32:51] heh, that was a full year ago [23:33:17] WilliamH, as i said eva@ is answered, but his anwer does not contain any information about the problem itself and the concrete things to fix that [23:34:36] ulm: So basically we made the decision and tried to dialog with the gnome team but they gave us nothing. [23:34:42] He went on and did actual QA work. Found that many related USE flags are completely wrongly used, and from there I am amazed the QA team is doing some stuff like that, when there are much bigger fish to fry than decide that USE flags are for declaring external dependencies instead of FEATURES. [23:35:12] The half-done work was linked to you from a spreadsheet by me, I have not heard of anything since on what to do about all those. [23:35:14] leio: everyone has their idea of what QA should be doing [23:35:31] and none of those ideas agree with any other person's idea [23:35:42] well, considering half of those USE=gtk's shouldn't be a USE=gtk at all... [23:36:16] anyways, I realized this is a meeting, [23:36:17] * leio shuts up [23:36:40] don't worry, it's boring anyway :P [23:36:57] leio: Should they be hard deps instead of use=gtk? [23:37:15] leio, you are free to attend the meeting and say your opinion about problem, do not worry about that [23:37:47] leio, and beeing in GNOME team makes your opinion even more valuable :-) [23:37:48] I do not have the time to read through the meeting log right now. Need to fix problems in the xorg/gtk/wayland/gles2 area. [23:38:28] But you are welcome to engage the GNOME team in the #gentoo-desktop channel. We hate e-mail. [23:41:06] So, who will be in charge of that conversation with GNOME team? I am all for making it as clear as it's possible, without enforcing rules, that are not apropriate because of some stupid misunderstanding [23:43:19] guys? [23:44:02] WilliamH, ^^ [23:45:00] I don't know, but if we had a valid policy, then I would just fix my few packages with IUSE=gtk [23:45:28] but I've postponed it because I feel that things are still in a pending state [23:46:01] ok, seems nobody wants to do this. I will take care about talking to GNOME team myself then. [23:46:04] ulm: I thought we had a valid policy... [23:46:06] and yes, we HAVE policy [23:46:11] but nobody enforces it [23:46:11] so e.g. emacs neither follows gnome nor qa policy [23:46:37] ok, so I will change flag usage there [23:47:52] gotta run [23:48:01] l8r :) [23:48:08] Pinkbyte: I don't know that I'm really qualified to do much since I don't use gnome myself. [23:48:36] WilliamH, sure, no problem. You are not the only QA team member :-/ [23:49:09] So, postponed until beeing discussed with GNOME team. "Status check: Followup on decisions of past QA and Council meeting" [23:49:18] not sure what's this about [23:50:25] !expn qa [23:50:26] Pinkbyte: qa = creffett,patrick,pinkbyte,tommy,ulm,williamh,wired,zerochaos,zlogene,mgorny,mrueg, [23:50:39] * mgorny has no clue [23:50:40] Guys, can we have some attention here, please? We are close to end the meeting [23:50:57] * WilliamH isn't sure either [23:51:01] I'm still here, just not sure I have anything to contribute [23:51:30] not sure, who has put this topic on the agenda? :) [23:51:31] * zlogene too [23:52:18] ulm, you! [23:52:24] oops https://wiki.gentoo.org/index.php?title=Project%3AQuality_Assurance%2FMeeting_Agenda&action=historysubmit&diff=256210&oldid=167544 [23:52:39] yeah, copied from previous meeting's agenda [23:52:44] logs does not lie, muahahaha :-P [23:53:17] well, next topic please :) [23:53:21] ok then [23:53:43] "open bugs with QA involvement" [23:53:53] https://bugs.gentoo.org/buglist.cgi?email2=qa%40gentoo.org&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype2=substring&list_id=2670328&query_format=advanced&resolution=--- [23:53:58] 210 open bugs [23:54:05] lol, ouch [23:54:50] well, i do not think we should discuss all of them now :-) [23:55:03] we have life, you know [23:55:46] who? ;o [23:55:53] anything concrete about open bugs? [23:55:57] life? [23:56:17] mgorny: can I close bug 539982? [23:56:22] ulm: https://bugs.gentoo.org/539982 "Unused licenses: CC-BY-ND-2.5, DSL, ECL-2.0, ODbL-1.0, intel-psb, mongrel, newton, urbanterror-4.1-maps"; Gentoo Linux, Unspecified; CONF; mgorny:licenses [23:56:33] sure, your choice [23:56:38] k [23:56:56] Damn I forgot all about the meeting :( [23:57:33] Zero_Chaos: can I close bug 537996? [23:57:36] WilliamH: https://bugs.gentoo.org/537996 ">=sys-apps/openrc-0.13 netmount script cannot properly mount nfs shares"; Gentoo Hosted Projects, OpenRC; CONF; zerochaos:openrc [23:57:49] WilliamH: not until it works, no [23:58:01] WilliamH: but you could ask the team to vote on it. [23:58:04] Zero_Chaos, what's the problem there? [23:58:13] Zero_Chaos: it does according to qa, and a new release was spun with "use" in the dependencies as requested. [23:58:17] Pinkbyte: /etc/init.d/netmount cannot start nfs mounts [23:58:33] Pinkbyte: you have to start another service first, but openrc currently lacks the ability to do it right. [23:58:41] Zero_Chaos, i clearly states how it should be done, did not i? [23:58:48] Pinkbyte: it is a config issue. he wants it to start them without having to type rc-update add nfsclient default [23:59:06] WilliamH, i remember that i answered clearly on that bug, did not i? [23:59:14] netmount is also not in the default runlevle [23:59:22] Pinkbyte: Yes, you did, and I followed your suggestion. [23:59:35] Zero_Chaos, and it is correct not beeing in default runlevel [23:59:38] Zero_Chaos: that's on you; you removed it. [23:59:59] WilliamH: your init script is missing deps. that's not my fault. [00:00:14] WilliamH: you know how I feel about this, why constantly ask if I reconsidered? [00:00:15] Zero_Chaos, not everybody uses NFS. And who did - they can follow proper procedure to configure it, including adding nfsclient to runlevel [00:00:28] WilliamH: I though we agreed to add 'want' or similar to openrc? [00:00:49]