From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 053911384B4 for ; Mon, 23 Nov 2015 16:46:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1530321C082; Mon, 23 Nov 2015 16:46:40 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7A20821C02A for ; Mon, 23 Nov 2015 16:46:39 +0000 (UTC) Received: from [192.168.0.13] (ip174-67-193-3.oc.oc.cox.net [174.67.193.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 4EAC2340139 for ; Mon, 23 Nov 2015 16:46:37 +0000 (UTC) Subject: Re: [gentoo-portage-dev] [PATCH] SyncManager: redirect command stderr to stdout (bug 566132) To: gentoo-portage-dev@lists.gentoo.org References: <1448223000-11588-1-git-send-email-zmedico@gentoo.org> <5652ECEB.8050909@gentoo.org> From: Zac Medico Message-ID: <565342EA.9060409@gentoo.org> Date: Mon, 23 Nov 2015 08:46:34 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <5652ECEB.8050909@gentoo.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 5753f2e5-69b4-43dc-97f2-5471b45cddb2 X-Archives-Hash: 7e5ac377daebb427934d7b756a635f12 On 11/23/2015 02:39 AM, Alexander Berntsen wrote: > Sorry for not being up to date what this does, but the bug complains > specifically about GitHub mirrors, while the patch itself seems far > more invasive. Is it the case that they should *never* go to STDERR? Since the sync modules can call a variety of different commands, it's hard to predict which ones will unnecessarily write to stderr. So, the assumption here is that the process exit status is a more reliable indicator for errors. For example, the python code in GitSync will write an error message to stderr if the git process exits with non-zero status. -- Thanks, Zac