From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 949AA138359 for ; Fri, 6 Nov 2020 08:39:45 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9B287E081A; Fri, 6 Nov 2020 08:39:42 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 60A00E0809 for ; Fri, 6 Nov 2020 08:39:42 +0000 (UTC) From: Agostino Sarubbo To: gentoo-dev@lists.gentoo.org, Joonas Niilola Subject: Re: [gentoo-dev] A feedback about the CI bug reporting system Date: Fri, 06 Nov 2020 09:39:35 +0100 Message-ID: <7169386.EvYhyI6sBW@spectre> In-Reply-To: <467e033f-91fb-724e-3770-efbd2f6e3d47@gentoo.org> References: <2044703.irdbgypaU6@spectre> <467e033f-91fb-724e-3770-efbd2f6e3d47@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Archives-Salt: f342db22-abe4-4f0c-beea-7c50cb0768ea X-Archives-Hash: e9bd92bf3c79a37b159a6f06954598e9 On venerd=EC 6 novembre 2020 09:18:50 CET Joonas Niilola wrote: > Would it be possible for "someone" to figure it out, if you made your > tinderbox scripts/code public? ;) Hate to say it, but toralf does pretty > good job here, so it could be better. As stated multiple times, toralf said that the way he's filing bugs expect = a=20 copy-paste action for the summary, this is not possible if you want to do t= hat=20 in a more automatic way. > Yes, I do find your tinderbox work useful most of the time. Thanks! > However the latest, ehh, show with DISTUTILS_USE_SETUPTOOLS has made > people do *hundreds* of commits that now apparently need a fixing > anyway, or reverting back, and that doesn't feel nice. Sure maybe the > eclass could do some fixing too, but maybe this notice wasn't meant to > be full-tree scanned (at least _yet_). This class of bugs comes from a request. Months ago I also asked if I had=20 report these bugs during the stabilization and I got a positive feedback. > From my point of view your work is, and has been, appreciated, but you > could coordinate better with other people. Hate to say it again, but > toralf does seems to do a better job here too in that regard. Unless > you're fine with comparing tinderboxers. > With toralf's logs it's easy to reproduce the whole environment leading > to a build failure, while with yours it's just build.log, thay may or > may not be enough to find the build-breaking issue. This is something already discussed (maybe privately?) and clearly state by= =20 me. If you say that with my logs you are unable to reproduce the issue, since I= 'm=20 providing emerge --info and build log, you are saying that those info are n= ot=20 enough. So, I'd suggest to fix this issue upstream by clearly defining what is need= ed=20 in a bug report, because AFAIK atm for a bug report is needed a build log a= nd=20 emerge --info If you want more info, why do not extend the emerge --info into for example= =20 emerge --info --extended instead of ask one by one to attach more info?? So the point is that there is no rule but just everyone ask without fixing = the=20 problem upstream. While you have a new option for detailed info, every people that run tinder= box=20 or just people that report bugs can use it. If you see an example of toralf bug, I can see: gcc-config -l: [1] x86_64-pc-linux-gnu-7.3.1 [2] x86_64-pc-linux-gnu-10.2.0 * clang version 11.0.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/11/bin /usr/lib/llvm/11 11.0.0 Available Python interpreters, in order of preference: [1] python3.7 [2] python3.9 (fallback) [3] python3.8 (fallback) [4] python2.7 (fallback) Available Ruby profiles: [1] ruby25 (with Rubygems) [2] ruby26 (with Rubygems) [3] ruby27 (with Rubygems) * Available Rust versions: [1] rust-bin-1.47.0 * The following VMs are available for generation-2: 1) IcedTea JDK 3.17.0 [icedtea-8] *) AdoptOpenJDK 8.272_p10 [openjdk-bin-8] Available Java Virtual Machines: [1] icedtea-8=20 [2] openjdk-bin-8 system-vm The Glorious Glasgow Haskell Compilation System, version 8.8.4 Again: why these info are not in emerge --info if are useful for a bugrepor= t? I'm sure you understand the concept Agostino