Re: [gentoo-portage-dev] [PATCH] repoman: mark errors with explicit '[fatal']
On Wed, 11 Feb 2015 00:52:27 +0100 Michał Górny mgo...@gentoo.org wrote: Mark fatal check results with explicit '[fatal]' marker to ease grepping and provide the additional information on non-colorful terminals as well. --- pym/repoman/utilities.py | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/pym/repoman/utilities.py b/pym/repoman/utilities.py index 4f01aa7..a2535f0 100644 --- a/pym/repoman/utilities.py +++ b/pym/repoman/utilities.py @@ -310,15 +310,18 @@ def format_qa_output(formatter, stats, fails, dofull, dofail, options, qawarning # we only want key value pairs where value 0 for category, number in \ filter(lambda myitem: myitem[1] 0, sorted(stats.items())): - formatter.add_literal_data( + category.ljust(30)) + formatter.add_literal_data( + category) + spacing_width = 30 - len(category) if category in qawarnings: formatter.push_style(WARN) else: formatter.push_style(BAD) + formatter.add_literal_data( [fatal]) + spacing_width -= 8 + + formatter.add_literal_data( * spacing_width) formatter.add_literal_data(%s % number) formatter.pop_style() - if category not in qawarnings: - formatter.add_literal_data( [fatal]) formatter.add_line_break() if not dofull: if not full and dofail and category in qawarnings: Works for me. merge approved -- Brian Dolbec dolsen
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
Rich Freeman: On Sun, Feb 8, 2015 at 12:38 PM, hasufell hasuf...@gentoo.org wrote: The council has (at least implicitly) stated that people may stop using common eclasses that standardize stuff in gentoo if they don't like them (that includes python, ruby, perl... eclasses as well, FYI). Maybe we should both step back a bit. The Council has said this, no more or less: - Motion: Every developer is allowed to commit and maintain games ebuilds, without the need to ask for permission or review from the games team. The games team does not have authority to override maintainer decisions on packages they don't maintain. Accepted unanimously. Note: This should be understood as clarification of existing policy. So can I commit to any category such as ruby, perl, haskell, sound, gnome without any sort of review too, no matter if I follow any sort of project standards (except following PMS)? - There is consensus amongst council members that specific policies (e.g., games group, /usr/games hierarchy, and games.eclass) should be settled by the QA team. They were not settled. - Motion: The council encourages the games team to accept join requests and elect a lead. In the event they don't elect a lead within 6 weeks, we will consider the team as dysfunctional and thus disband it. Accepted with 6 yes votes and 1 abstention. This is offtopic, but what's the status? Who is the new lead?
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: toolchain.eclass
Dnia 2015-02-09, o godz. 20:19:49 Anthony G. Basile bluen...@gentoo.org napisał(a): On 02/09/15 06:40, Michał Górny wrote: This breaks a few packages [1,2]. Please fix the breakage and run repoman next time. [1]:https://travis-ci.org/gentoo/gentoo-portage-rsync-mirror/jobs/50118225#L4304 [2]:https://travis-ci.org/gentoo/gentoo-portage-rsync-mirror/jobs/50118228#L923 Someone has a shiny new toy :) Seriously this is great, but asking someone to run repoman when making a change to an eclass is extreme. You'd have to run it against the whole tree and while I haven't timed it, that's going to be a heavy task. In my late announcement, I suggested that people can file Pull Requests to get the travis run automatically. -- Best regards, Michał Górny pgps7m4otSyz_.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
On 2015-02-10 12:38, hasufell wrote: - Motion: The council encourages the games team to accept join requests and elect a lead. In the event they don't elect a lead within 6 weeks, we will consider the team as dysfunctional and thus disband it. Accepted with 6 yes votes and 1 abstention. This is offtopic, but what's the status? Who is the new lead? This was mostly contingent on new people joining the games herd, from what comments I got back no one really wanted to join (at least under the current system). I wasn't going to force the games team to elect a new lead when it appears none cared much at that point who the lead was. Also, I would advise caution on considering it dysfunctional and disbanding it due to this. To reinforce the point that's been said before, if people want the status quo to change the most direct route is often joining and making changes, not standing on the sidelines asking for change. Thanks, Tim signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
Tim Harder: On 2015-02-10 12:38, hasufell wrote: - Motion: The council encourages the games team to accept join requests and elect a lead. In the event they don't elect a lead within 6 weeks, we will consider the team as dysfunctional and thus disband it. Accepted with 6 yes votes and 1 abstention. This is offtopic, but what's the status? Who is the new lead? This was mostly contingent on new people joining the games herd, from what comments I got back no one really wanted to join (at least under the current system). I wasn't going to force the games team to elect a new lead when it appears none cared much at that point who the lead was. Also, I would advise caution on considering it dysfunctional and disbanding it due to this. I cannot follow that argumentation. Because no one wants to join, the team is functional?
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
On Tue, Feb 10, 2015 at 12:38 PM, hasufell hasuf...@gentoo.org wrote: Rich Freeman: On Sun, Feb 8, 2015 at 12:38 PM, hasufell hasuf...@gentoo.org wrote: The council has (at least implicitly) stated that people may stop using common eclasses that standardize stuff in gentoo if they don't like them (that includes python, ruby, perl... eclasses as well, FYI). Maybe we should both step back a bit. The Council has said this, no more or less: - Motion: Every developer is allowed to commit and maintain games ebuilds, without the need to ask for permission or review from the games team. The games team does not have authority to override maintainer decisions on packages they don't maintain. Accepted unanimously. Note: This should be understood as clarification of existing policy. So can I commit to any category such as ruby, perl, haskell, sound, gnome without any sort of review too, no matter if I follow any sort of project standards (except following PMS)? If you maintain a package that uses ruby/perl/haskell/gnome, or even, heaven forbid, sound, you can maintain it as you wish as long as you generally follow general policy. Of course, if your package doesn't work it is subject to QA, and if you don't follow the guidelines issued by those groups it is more likely to end up not working at some point. Why you'd want to re-invent the wheel vs just using their eclasses is beyond me. That doesn't mean that you can just mess with packages that make up ruby/perl/gnome/haskell, etc (not really sure how sound fits into that). They are maintained by various project teams that operate as a team. The issue here was projects in general claiming monopolies on entire genres of software. You don't need the blessing of the games team to maintain a game. Heck, you'd be hard-pressed to even define what is and isn't a game anyway. We also found that many games were already not using the eclass (such as anything bundled with kde/gnome/etc). Tim's response covered the rest of your email fairly well, so I won't repeat it. QA did note that they're going to be taking a closer look at games in today's Council meeting. -- Rich
[gentoo-portage-dev] [PATCH] repoman: mark errors with explicit '[fatal']
Mark fatal check results with explicit '[fatal]' marker to ease grepping and provide the additional information on non-colorful terminals as well. --- pym/repoman/utilities.py | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/pym/repoman/utilities.py b/pym/repoman/utilities.py index 4f01aa7..a2535f0 100644 --- a/pym/repoman/utilities.py +++ b/pym/repoman/utilities.py @@ -310,15 +310,18 @@ def format_qa_output(formatter, stats, fails, dofull, dofail, options, qawarning # we only want key value pairs where value 0 for category, number in \ filter(lambda myitem: myitem[1] 0, sorted(stats.items())): - formatter.add_literal_data( + category.ljust(30)) + formatter.add_literal_data( + category) + spacing_width = 30 - len(category) if category in qawarnings: formatter.push_style(WARN) else: formatter.push_style(BAD) + formatter.add_literal_data( [fatal]) + spacing_width -= 8 + + formatter.add_literal_data( * spacing_width) formatter.add_literal_data(%s % number) formatter.pop_style() - if category not in qawarnings: - formatter.add_literal_data( [fatal]) formatter.add_line_break() if not dofull: if not full and dofail and category in qawarnings: -- 2.3.0
