From owner-freebsd-ports@freebsd.org Mon May 17 02:19:37 2021 Return-Path: Delivered-To: freebsd-ports@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4F8A9639138 for ; Mon, 17 May 2021 02:19:37 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fk2rm1mp2z3RB5; Mon, 17 May 2021 02:19:35 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 14H2JSe1067302 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 16 May 2021 19:19:28 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 14H2JSoI067301; Sun, 16 May 2021 19:19:28 -0700 (PDT) (envelope-from fbsd) Date: Sun, 16 May 2021 19:19:27 -0700 From: bob prohaska To: Kubilay Kocak Cc: FreeBSD ports Subject: Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4 Message-ID: <20210517021927.GA66198@www.zefox.net> References: <515FCC01-19A2-463C-8416-85D0BF0B4845.ref@yahoo.com> <515FCC01-19A2-463C-8416-85D0BF0B4845@yahoo.com> <20210514013518.GA46967@www.zefox.net> <18651bb2-4093-af83-da8f-d57553fffc9d@FreeBSD.org> <20210514163514.GA52420@www.zefox.net> <802898bf-fb68-f648-b893-1bebb02d9c16@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <802898bf-fb68-f648-b893-1bebb02d9c16@FreeBSD.org> X-Rspamd-Queue-Id: 4Fk2rm1mp2z3RB5 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [-1.06 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[50.1.20.27:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[50.1.20.27:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-0.96)[-0.960]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ports]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 02:19:37 -0000 On Sun, May 16, 2021 at 12:24:49PM +1000, Kubilay Kocak wrote: > On 15/05/2021 2:35 am, bob prohaska wrote: > > > > I've never used IRC, is it somehow better than this list? > > Quicker isolation of root causes over async back and forth. Happy to go over > it with you at your favourite 'real-time medium' No real favorites. In emergencies I tend to pick up the telephone. This doesn't seem like an emergency, and in any case the phone is a poor medium for a problem like this. There are some ports under /usr/ports/irc, if you have suggestions I could try one or more. If a phone call is useful, my number is 530 753 2005, California PDT. The answering machine screens calls, I pick up if I recognize the caller's message. I can return calls anywhere in the lower 48. It's important to remember that even if the comms delay is zero my comprehension delay is much greater than zero. Sometimes infinite. That's apt to either bore or frustrate experts. Mark Millard is trying to give me an inkling of how poudriere works. It's a stunningly complex process, apparently approximating individual virtual hosts compiling each port. I'd like to see the ports system keep working as it has in the past, but that seemingly requires a kind of machine intelligence that hasn't evolved yet. Poudriere seems like a brute force approach. Persuading ports (and porters) to cooperate is more efficient if it's possible. Thanks for reading, and any thoughts you might have! bob prohaska