From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 17 09:03:49 2021 Received: (at submit) by debbugs.gnu.org; 17 Dec 2021 14:03:49 +0000 Received: from localhost ([127.0.0.1]:38316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1myDps-0004g4-LJ for submit@debbugs.gnu.org; Fri, 17 Dec 2021 09:03:48 -0500 Received: from lists.gnu.org ([209.51.188.17]:44578) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1myDpr-0004fx-4D for submit@debbugs.gnu.org; Fri, 17 Dec 2021 09:03:47 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57976) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1myDpp-0003Jd-T8 for bug-guix@gnu.org; Fri, 17 Dec 2021 09:03:45 -0500 Received: from h87-96-130-155.cust.a3fiber.se ([87.96.130.155]:48348 helo=mail.yoctocell.xyz) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1myDpn-0002j0-9N for bug-guix@gnu.org; Fri, 17 Dec 2021 09:03:45 -0500 From: Xinglu Chen DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yoctocell.xyz; s=mail; t=1639749818; bh=W0fFGh3qfX1MtL7gbmEc8I8wEeGLZEvDdFtl9714zQE=; h=From:To:Subject:Date; b=dxEzH2jVdwHphCXn5yA8AZQ/p0A5j8KqZSt01xOE6JMyvnrxljyjRwe4BS/d8M3OI JxUhzGyir4WXsD91RSA/ovXZj9gkntHkKgl5xxlFI+9x9Sp5XLAFx+Ug2IzRxHoCUm kLBvJ5e+KZTzG2SFF3g62acPMgdBgQdmYlEK1yXg= To: bug-guix@gnu.org Subject: =?utf-8?B?4oCYZ3VpeCBsaW504oCZ?= throws an ugly backtrace if the GitHub updater receives =?utf-8?Q?=E2=80=9Crate?= limit =?utf-8?Q?exceeded=E2=80=9D?= error Date: Fri, 17 Dec 2021 15:03:36 +0100 Message-ID: <87bl1fjpl3.fsf@disroot.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Received-SPF: pass client-ip=87.96.130.155; envelope-from=public@yoctocell.xyz; helo=mail.yoctocell.xyz X-Spam_score_int: 53 X-Spam_score: 5.3 X-Spam_bar: +++++ X-Spam_report: (5.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_SUSPICIOUS_NTLD=0.498, FROM_SUSPICIOUS_NTLD_FP=0.295, PDS_OTHER_BAD_TLD=1.997, PDS_RDNS_DYNAMIC_FP=0.001, RCVD_IN_PBL=3.335, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TO_NO_BRKTS_DYNIP=0.245 autolearn=no autolearn_force=no X-Spam_action: reject X-Spam-Score: 1.7 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: When running ‘guix lint -c refresh’ on a package hosted on GitHub, I get an ugly backtrace when the GitHub rate limit has been reached. --88--- $ guix lint pipewire fetching CVE database for 2021... fetching CVE database for 2018... Backtrace:ipewire@0.3.29 [refresh]... 15 (pri [...] Content analysis details: (1.7 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: yoctocell.xyz (xyz)] 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.51.188.17 listed in wl.mailspike.net] -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [209.51.188.17 listed in list.dnswl.org] 0.5 FROM_SUSPICIOUS_NTLD_FP From abused NTLD 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.1 (/) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable When running =E2=80=98guix lint -c refresh=E2=80=99 on a package hosted on = GitHub, I get an ugly backtrace when the GitHub rate limit has been reached. =2D-8<---------------cut here---------------start------------->8--- $ guix lint pipewire fetching CVE database for 2021... fetching CVE database for 2018... Backtrace:ipewire@0.3.29 [refresh]... 15 (primitive-load "/home/yoctocell/.config/guix/current/b=E2=80= =A6") In guix/ui.scm: 2206:7 14 (run-guix . _) 2169:10 13 (run-guix-command _ . _) In ice-9/boot-9.scm: 1752:10 12 (with-exception-handler _ _ #:unwind? _ # _) 1752:10 11 (with-exception-handler _ _ #:unwind? _ # _) In guix/store.scm: 658:37 10 (thunk) In srfi/srfi-1.scm: 634:9 9 (for-each # =E2=80=A6) In guix/scripts/lint.scm: 65:4 8 (run-checkers _ _ #:store _) In srfi/srfi-1.scm: 634:9 7 (for-each # =E2=80=A6) In guix/scripts/lint.scm: 74:21 6 (_ _) In guix/lint.scm: 1428:5 5 (check-for-updates #) 771:2 4 (call-with-networking-fail-safe _ _ _) In ice-9/boot-9.scm: 1752:10 3 (with-exception-handler _ _ #:unwind? _ # _) 1685:16 2 (raise-exception _ #:continuable? _) 1683:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1685:16: In procedure raise-exception: ERROR: 1. &http-get-error: uri: #< scheme: https userinfo: #f host: "api.github.com" port: = #f path: "/repos/PipeWire/pipewire/releases" query: #f fragment: #f> code: 403 reason: "rate limit exceeded" 2. &message: "https://api.github.com/repos/PipeWire/pipewire/releases: HT= TP download failed: 403 (\"rate limit exceeded\")" =2D-8<---------------cut here---------------end--------------->8--- When running =E2=80=98guix refresh=E2=80=99, a much friendlier error messag= e is produced. =2D-8<---------------cut here---------------start------------->8--- $ guix refresh -t github guix refresh: error: https://api.github.com/repos/OpenZWave/open-zwave/rele= ases: HTTP download failed: 403 ("rate limit exceeded") =2D-8<---------------cut here---------------end--------------->8--- The problem seems to be that the =E2=80=98check-for-updates=E2=80=99 proced= ure in (guix lint) doesn=E2=80=99t catch the =E2=80=98&http-get-error=E2=80=99. I tried= adding the following form: =2D-8<---------------cut here---------------start------------->8--- (guard (c ((and (http-get-error? c) (string=3D? "rate limit exceeded" (http-get-error-reason c))) (warning (G_ "GitHub rate limit exceeded")) #f)) (with-networking-fail-safe ...)) =2D-8<---------------cut here---------------end--------------->8--- but it doesn=E2=80=99t work. C seems to be something a lot more complicated than just a =E2=80=98&http-get-error=E2=80=99: =2D-8<---------------cut here---------------start------------->8--- #<&compound-exception components: (#<&error> #<&irritants irritants: (#<&co= mpound-exception components: (#<&http-get-error uri: #< scheme: https = userinfo: #f host: "api.github.com" port: #f path: "/repos/PipeWire/pipewir= e/releases" query: #f fragment: #f> code: 403 reason: "rate limit exceeded"= > #<&message message: "https://api.github.com/repos/PipeWire/pipewire/relea= ses: HTTP download failed: 403 (\"rate limit exceeded\")">)>)> #<&exception= -with-kind-and-args kind: %exception args: (#<&compound-exception component= s: (#<&http-get-error uri: #< scheme: https userinfo: #f host: "api.gi= thub.com" port: #f path: "/repos/PipeWire/pipewire/releases" query: #f frag= ment: #f> code: 403 reason: "rate limit exceeded"> #<&message message: "htt= ps://api.github.com/repos/PipeWire/pipewire/releases: HTTP download failed:= 403 (\"rate limit exceeded\")">)>)>)> =2D-8<---------------cut here---------------end--------------->8--- Any ideas on how to extract to the =E2=80=98&http-get-error=E2=80=99? --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJJBAEBCAAzFiEEAVhh4yyK5+SEykIzrPUJmaL7XHkFAmG8mLkVHHB1YmxpY0B5 b2N0b2NlbGwueHl6AAoJEKz1CZmi+1x5PDoP/3fUDQQMLHfcP/1+dg3qwwJ8hkO3 7Rv+Fuy2gFF2Gf/bCqY3dPEfMYoddKTzWqxJNf2ImalSoMdPGNx0JJS7nkVTJygg ETsKxGMcyYfBfSRcmxKH1NHkQnrjw4ZB4ih1OvUDpGaV2ZJDOetgELh0lNaDjznr 8s5EtjVn78SBVYJMgi6MFLtyow4d/7wM1lyt5nftO8BdOmW2WkM8KXYYVSpGfbfK aSh+EKIFAVFHBYLwTXnSTmdaP5CydWIMmEiUkzmi88pmmYfQVI2Kzvku0THX9C3E 78oN/PWc/Xjcipz/o5PcXYYoSYwmpuqpUGNjg6blwCG+9S0f7XwYE5E81mlsMaog IIwYhqDSqxaywKtKgFXW2aMDFQSYt0v6naqdxEa4nDfpoL+CoFxkhBInxeoCwqYl mxjN5y1ncC1Fjq4+2Xn9bNyXqN3Q2xu5YYUwvjXMZVSfN/rYZRyKKB6yirOWN0my 5+wl591PKxSp3c05Z2uOHZGgoZ1mJ6KOaFc9q2nTeL3MCPtYz9M72wmFaHks9NRv ZEefS485JqsTPvVpaERGfGV571Yiu+72a6bRMkf/omHiinulqXImcOL6TDmgVWdQ YNXOkzOuNY5/I/U83Eu7M4yHy/BXj7o62Noz0pOztEagMaoe1o3PzMfZWhywjw1R icMMKr78cMgQpBQ5 =hlsS -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 17 11:29:42 2021 Received: (at 52577) by debbugs.gnu.org; 17 Dec 2021 16:29:43 +0000 Received: from localhost ([127.0.0.1]:40506 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1myG74-00033i-Li for submit@debbugs.gnu.org; Fri, 17 Dec 2021 11:29:42 -0500 Received: from albert.telenet-ops.be ([195.130.137.90]:37838) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1myG72-00033Z-87 for 52577@debbugs.gnu.org; Fri, 17 Dec 2021 11:29:41 -0500 Received: from ptr-bvsjgyhxw7psv60dyze.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:3c5f:2eff:feb0:ba5a]) by albert.telenet-ops.be with bizsmtp id XUVe260144UW6Th06UVepq; Fri, 17 Dec 2021 17:29:38 +0100 Message-ID: <746d29cab94d0a8686283a896cd2f639523e9d5d.camel@telenet.be> Subject: Re: bug#52577: =?UTF-8?Q?=E2=80=98guix?= =?UTF-8?Q?_lint=E2=80=99?= throws an ugly backtrace if the GitHub updater receives =?UTF-8?Q?=E2=80=9Crate?= limit =?UTF-8?Q?exceeded=E2=80=9D?= error From: Maxime Devos To: Xinglu Chen , 52577@debbugs.gnu.org Date: Fri, 17 Dec 2021 16:29:35 +0000 In-Reply-To: <87bl1fjpl3.fsf@disroot.org> References: <87bl1fjpl3.fsf@disroot.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r21; t=1639758578; bh=MkkN5wy2cH5uL0xmb5ApYmLoCcHhN1cflRn+C7byaxE=; h=Subject:From:To:Date:In-Reply-To:References; b=DM4drYrjmHB72Ibyxc2vbPJ5pLoXEI9x90kL/u3qAtkXl83dUTA1SHPvI7Dq3kfYS ZLAOikzTqmU1Z5mMeDiZoRimTFVaCKfeUTSv+sclpsNmBvB7RyUfxOMwF9J8Kw5Jp5 8UZKP62mk8NjdMvQDWVF2lwYexVQHKhbTOqYyo/kwBVbaFvR10jboRc1DpVmlejPUp EbEWBH8SQEkZrKrXT36d+iRgVqtHCc3L+vQu3q91Zlfj4GDah+tGuMOjsL8Ruc3tcM 8rWL0G+Z2+fNxDLbAcIJFBxwKl1kmk0cA3XId01L1XinZ5nQDX+g9SQbQRMuJDft0u h5vqsyx2bkaLw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 52577 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Xinglu Chen schreef op vr 17-12-2021 om 15:03 [+0100]: > (guard (c ((and (http-get-error? c) >                 (string=? "rate limit exceeded" >                           (http-get-error-reason c))) >            (warning (G_ "GitHub rate limit exceeded")) >            #f)) >   (with-networking-fail-safe ...)) Shouldn't this be wrapped the other way around? Or maybe even move the http-get-error?+string=?+warning inside call-with-networking-fail-safe? If you do the latter, you'll have to check the 'uri' field of the &http-get-error to determine if it's GitHub, and not, say, SWH or the CVE database or something. Greetings, Maxime. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 19 06:58:30 2021 Received: (at 52577) by debbugs.gnu.org; 19 Dec 2021 11:58:30 +0000 Received: from localhost ([127.0.0.1]:45000 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1myuph-0003Bd-Sc for submit@debbugs.gnu.org; Sun, 19 Dec 2021 06:58:30 -0500 Received: from xavier.telenet-ops.be ([195.130.132.52]:45946) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1myupf-0003BE-ES for 52577@debbugs.gnu.org; Sun, 19 Dec 2021 06:58:28 -0500 Received: from ptr-bvsjgyhxw7psv60dyze.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:3c5f:2eff:feb0:ba5a]) by xavier.telenet-ops.be with bizsmtp id YByR260024UW6Th01ByRKC; Sun, 19 Dec 2021 12:58:25 +0100 Message-ID: <80e40710ed0814ecded0d7f153d1e1ef6e30a311.camel@telenet.be> Subject: Re: bug#52577: =?UTF-8?Q?=E2=80=98guix?= =?UTF-8?Q?_lint=E2=80=99?= throws an ugly backtrace if the GitHub updater receives =?UTF-8?Q?=E2=80=9Crate?= limit =?UTF-8?Q?exceeded=E2=80=9D?= error From: Maxime Devos To: Xinglu Chen , 52577@debbugs.gnu.org Date: Sun, 19 Dec 2021 11:58:25 +0000 In-Reply-To: <87sfurhru8.fsf@disroot.org> References: <87bl1fjpl3.fsf@disroot.org> <746d29cab94d0a8686283a896cd2f639523e9d5d.camel@telenet.be> <87sfurhru8.fsf@disroot.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r21; t=1639915105; bh=Hn9mp0eJczWtHCnmBuHLk95wBxzsdlTLlaW+RbYV5M4=; h=Subject:From:To:Date:In-Reply-To:References; b=Hwlzsxp65+6E0E8uARD5qVsdQEfu+4mP6WVzE5PGuY4n1Pbx27HDKWEoWykQQCPkL bNhnjOWVqxLoajE6tSRWsGbB547A1ag89VlXN/PLTmHdTvccbFjwh9r23SE5Kx8PuY qAcynwpHNDoAIVesndQn3EgLMaI/8WJj29U3PBV4iFeWsb/he7pU3635kYtUlE+EHi GPlNHvWMOThjv0jJGvbGos6EBjDtNR9SgUrdDMqoQuVxMiWlf3UrRxNcpvr3+InIz2 iry6gaQbYI22+gP54be0qm3/0Op4vTi4kHQWjr5x87vASfAUAbQY99msjBbivqpuNO np+mqoIwl7Amg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 52577 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Xinglu Chen schreef op vr 17-12-2021 om 21:57 [+0100]: > On Fri, Dec 17 2021, Maxime Devos wrote: > > > Xinglu Chen schreef op vr 17-12-2021 om 15:03 [+0100]: > > > (guard (c ((and (http-get-error? c) > > >                 (string=? "rate limit exceeded" > > >                           (http-get-error-reason c))) > > >            (warning (G_ "GitHub rate limit exceeded")) > > >            #f)) > > >   (with-networking-fail-safe ...)) > > > > Shouldn't this be wrapped the other way around? > > Or maybe even move the http-get-error?+string=?+warning inside > > call-with-networking-fail-safe? > > Thanks for the pointer, it seems that ‘throw’ in > ‘call-with-networking-fail-safe’ wraps the original exception an > additional ‘&compound-exception’.  Before the ‘throw’, the exception > looks like this: > > --8<---------------cut here---------------start------------->8--- > (%exception #<&compound-exception components: (#<&http-get-error uri: > #< scheme: https userinfo: #f host: "api.github.com" port: #f > path: "/repos/PipeWire/pipewire/releases" query: #f fragment: #f> > code: 403 reason: "rate limit exceeded"> #<&message message: " > https://api.github.com/repos/PipeWire/pipewire/releases: HTTP > download failed: 403 (\"rate limit exceeded\")">)>) > --8<---------------cut here---------------end--------------->8--- > > After the ‘throw’, it becomes this: > > --8<---------------cut here---------------start------------->8--- > #<&compound-exception components: (#<&error> #<&irritants irritants: > (#<&compound-exception > components: (#<&http-get-error uri: #< scheme: https userinfo: > #f host: > "api.github.com" port: #f path: "/repos/PipeWire/pipewire/releases" > query: #f fragment: #f> > code: 403 reason: "rate limit exceeded"> #<&message message: > "https://api.github.com/repos/PipeWire/pipewire/releases: HTTP > download failed: 403 (\"rate > limit exceeded\")">)>)> #<&exception-with-kind-and-args kind: > %exception args: > (#<&compound-exception components: (#<&http-get-error uri: #< > scheme: https userinfo: > #f host: "api.github.com" port: #f path: > "/repos/PipeWire/pipewire/releases" query: #f > fragment: #f> code: 403 reason: "rate limit exceeded"> #<&message > message: > "https://api.github.com/repos/PipeWire/pipewire/releases: HTTP > download failed: 403 (\"rate > limit exceeded\")">)>)>)> > --8<---------------cut here---------------end--------------->8--- > > This means that the ‘guard’ form in ‘call-with-networking-fail-safe’ > is > never going to match anything since the real exception will always be > nested > in another ‘&compound-exception’. Actually, being wrapped in &compound-exception shouldn't be a problem: &compound-exception just means that the exception is of multiple types, e.g. both &message and &http-get-error or something like that. In that case, the exception could be both message? and http-get-error?. I think the problem is, that for some unknown reason, the &http-get-error/&message exception gets wrapped in a &exception-with-and-args --- I guess there's a bad interaction with the throw/catch exception handling system and the raise/guard system, because only 'system-error'/'tls-certificate-error'/...-style exceptions should get wrapped in a &exception-with-kind-and-arguments. Greetings, Maxime From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 21 12:17:21 2021 Received: (at 52577) by debbugs.gnu.org; 21 Dec 2021 17:17:21 +0000 Received: from localhost ([127.0.0.1]:55438 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzilM-00057F-TR for submit@debbugs.gnu.org; Tue, 21 Dec 2021 12:17:21 -0500 Received: from h87-96-130-155.cust.a3fiber.se ([87.96.130.155]:60574 helo=mail.yoctocell.xyz) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzilK-00056w-8M for 52577@debbugs.gnu.org; Tue, 21 Dec 2021 12:17:19 -0500 From: Xinglu Chen DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yoctocell.xyz; s=mail; t=1640107030; bh=/PNaqzix59fck2dHV8VMOA8fspL+dogJ7Z/UNqerhL8=; h=From:To:Subject:In-Reply-To:References:Date; b=dd9wkexiw6POoFJktSR3zZhh4tciSc2ebdLwnWiVI2bz+Pk6vhpnMrJadpDjZZuej P7UwbUeb9ZAwtDfbCKBkVOm125S4FQQOKM3qRh1n1SQztM+SGkyyTDC67rLC4rpvZ0 NIQB3JqS8s2JX0m4YOvE9wFpom9PnyLUkd1SVaEk= To: Maxime Devos , 52577@debbugs.gnu.org Subject: Re: bug#52577: =?utf-8?B?4oCYZ3VpeCBsaW504oCZ?= throws an ugly backtrace if the GitHub updater receives =?utf-8?Q?=E2=80=9Crate?= limit =?utf-8?Q?exceeded?= =?utf-8?Q?=E2=80=9D?= error In-Reply-To: <80e40710ed0814ecded0d7f153d1e1ef6e30a311.camel@telenet.be> References: <87bl1fjpl3.fsf@disroot.org> <746d29cab94d0a8686283a896cd2f639523e9d5d.camel@telenet.be> <87sfurhru8.fsf@disroot.org> <80e40710ed0814ecded0d7f153d1e1ef6e30a311.camel@telenet.be> Date: Tue, 21 Dec 2021 18:17:08 +0100 Message-ID: <87wnjxev3f.fsf@yoctocell.xyz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Spam-Score: 2.9 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On So, Dez 19 2021, Maxime Devos wrote: > Xinglu Chen schreef op vr 17-12-2021 om 21:57 [+0100]: >> On Fri, Dec 17 2021, Maxime Devos wrote: >> >> > Xinglu Chen schreef op vr 17-12-2021 om 15:03 [+0100]: >> > > (guard (c ((and (http-get-err [...] Content analysis details: (2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: yoctocell.xyz (xyz)] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD 0.4 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS 0.0 PDS_RDNS_DYNAMIC_FP RDNS_DYNAMIC with FP steps X-Debbugs-Envelope-To: 52577 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.9 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On So, Dez 19 2021, Maxime Devos wrote: > Xinglu Chen schreef op vr 17-12-2021 om 21:57 [+0100]: >> On Fri, Dec 17 2021, Maxime Devos wrote: >> >> > Xinglu Chen schreef op vr 17-12-2021 om 15:03 [+0100]: >> > > (guard (c ((and (http-get-err [...] Content analysis details: (2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: yoctocell.xyz (xyz)] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD 0.4 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS 1.0 BULK_RE_SUSP_NTLD Precedence bulk and RE: from a suspicious TLD -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager 0.0 PDS_RDNS_DYNAMIC_FP RDNS_DYNAMIC with FP steps --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On So, Dez 19 2021, Maxime Devos wrote: > Xinglu Chen schreef op vr 17-12-2021 om 21:57 [+0100]: >> On Fri, Dec 17 2021, Maxime Devos wrote: >>=20 >> > Xinglu Chen schreef op vr 17-12-2021 om 15:03 [+0100]: >> > > (guard (c ((and (http-get-error? c) >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 (string=3D? "rate limit exceeded" >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 (http-get-error-reason c))) >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (warnin= g (G_ "GitHub rate limit exceeded")) >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #f)) >> > > =C2=A0 (with-networking-fail-safe ...)) >> >=20 >> > Shouldn't this be wrapped the other way around? >> > Or maybe even move the http-get-error?+string=3D?+warning inside >> > call-with-networking-fail-safe? >>=20 >> Thanks for the pointer, it seems that =E2=80=98throw=E2=80=99 in >> =E2=80=98call-with-networking-fail-safe=E2=80=99 wraps the original exce= ption an >> additional =E2=80=98&compound-exception=E2=80=99.=C2=A0 Before the =E2= =80=98throw=E2=80=99, the exception >> looks like this: >>=20 >> --8<---------------cut here---------------start------------->8--- >> (%exception #<&compound-exception components: (#<&http-get-error uri: >> #< scheme: https userinfo: #f host: "api.github.com" port: #f >> path: "/repos/PipeWire/pipewire/releases" query: #f fragment: #f> >> code: 403 reason: "rate limit exceeded"> #<&message message: " >> https://api.github.com/repos/PipeWire/pipewire/releases: HTTP >> download failed: 403 (\"rate limit exceeded\")">)>) >> --8<---------------cut here---------------end--------------->8--- >>=20 >> After the =E2=80=98throw=E2=80=99, it becomes this: >>=20 >> --8<---------------cut here---------------start------------->8--- >> #<&compound-exception components: (#<&error> #<&irritants irritants: >> (#<&compound-exception >> components: (#<&http-get-error uri: #< scheme: https userinfo: >> #f host: >> "api.github.com" port: #f path: "/repos/PipeWire/pipewire/releases" >> query: #f fragment: #f> >> code: 403 reason: "rate limit exceeded"> #<&message message: >> "https://api.github.com/repos/PipeWire/pipewire/releases: HTTP >> download failed: 403 (\"rate >> limit exceeded\")">)>)> #<&exception-with-kind-and-args kind: >> %exception args: >> (#<&compound-exception components: (#<&http-get-error uri: #< >> scheme: https userinfo: >> #f host: "api.github.com" port: #f path: >> "/repos/PipeWire/pipewire/releases" query: #f >> fragment: #f> code: 403 reason: "rate limit exceeded"> #<&message >> message: >> "https://api.github.com/repos/PipeWire/pipewire/releases: HTTP >> download failed: 403 (\"rate >> limit exceeded\")">)>)>)> >> --8<---------------cut here---------------end--------------->8--- >>=20 >> This means that the =E2=80=98guard=E2=80=99 form in =E2=80=98call-with-n= etworking-fail-safe=E2=80=99 >> is >> never going to match anything since the real exception will always be >> nested >> in another =E2=80=98&compound-exception=E2=80=99. > > Actually, being wrapped in &compound-exception shouldn't be a problem: > &compound-exception just means that the exception is of multiple types, > e.g. both &message and &http-get-error or something like that. In that > case, the exception could be both message? and http-get-error?. > > I think the problem is, that for some unknown reason, the > &http-get-error/&message exception gets wrapped in a > &exception-with-and-args --- I guess there's a bad interaction with > the throw/catch exception handling system and the raise/guard system, > because only 'system-error'/'tls-certificate-error'/...-style > exceptions should get wrapped in a &exception-with-kind-and-arguments. Yeah, the catch/throw system doesn=E2=80=99t really work well with =E2=80= =98raise=E2=80=99. Here is what I found after some digging: (catch KIND THUNK HANDLER) uses =E2=80=98exception-kind=E2=80=99 to determi= ne the kind of the exception. Since =E2=80=98&http-get-error=E2=80=99 was created usin= g =E2=80=98raise=E2=80=99, it doesn=E2=80=99t really have a notion of a =E2=80=9Ckind=E2=80=9D, therefore= , =E2=80=98exception-kind=E2=80=99 returns the =E2=80=98%exception=E2=80=99 symbol. I guess that=E2=80=99s wh= y I had to match on ('%exception exception) to match the =E2=80=98&http-get-error=E2=80=99 Excerpt from the patch I attached: (catch #t proc (match-lambda* ... ((and ('%exception exception) (http-get-error? exception)) ...) ...)) --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-lint-Fix-handling-of-HTTP-errors.patch Content-Transfer-Encoding: quoted-printable From=20cf1f08ba8f4c9866ab0077cc50941133ba4ff77b Mon Sep 17 00:00:00 2001 Message-Id: From: Xinglu Chen Date: Fri, 17 Dec 2021 21:32:51 +0100 Subject: [PATCH] lint: Fix handling of HTTP errors. MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit The 'catch' call would wrap the '&http-get-error' error in an '%exception' meaning that the 'guard' form would never catch a '&http-get-error'. It se= ems that the throw/catch system doesn't play nicely with the raise/guard system. * guix/lint.scm (call-with-networking-fail-safe): Add pattern to match '&http-get-error'; handle GitHub rate limit error; remove 'guard' form. Fixes: =2D-- guix/lint.scm | 80 ++++++++++++++++++++++++++++----------------------- 1 file changed, 44 insertions(+), 36 deletions(-) diff --git a/guix/lint.scm b/guix/lint.scm index 403f343b6c..67b2bb7221 100644 =2D-- a/guix/lint.scm +++ b/guix/lint.scm @@ -801,43 +801,51 @@ (define response (define (call-with-networking-fail-safe message error-value proc) "Call PROC catching any network-related errors. Upon a networking error, display a message including MESSAGE and return ERROR-VALUE." =2D (guard (c ((http-get-error? c) =2D (warning (G_ "~a: HTTP GET error for ~a: ~a (~s)~%") =2D message =2D (uri->string (http-get-error-uri c)) =2D (http-get-error-code c) =2D (http-get-error-reason c)) =2D error-value)) =2D (catch #t =2D proc =2D (match-lambda* =2D (('getaddrinfo-error errcode) =2D (warning (G_ "~a: host lookup failure: ~a~%") =2D message =2D (gai-strerror errcode)) =2D error-value) =2D (('tls-certificate-error args ...) =2D (warning (G_ "~a: TLS certificate error: ~a") =2D message =2D (tls-certificate-error-string args)) =2D error-value) =2D (('gnutls-error error function _ ...) =2D (warning (G_ "~a: TLS error in '~a': ~a~%") + (catch #t + proc + (match-lambda* + (('getaddrinfo-error errcode) + (warning (G_ "~a: host lookup failure: ~a~%") + message + (gai-strerror errcode)) + error-value) + (('tls-certificate-error args ...) + (warning (G_ "~a: TLS certificate error: ~a") + message + (tls-certificate-error-string args)) + error-value) + (('gnutls-error error function _ ...) + (warning (G_ "~a: TLS error in '~a': ~a~%") + message + function (error->string error)) + error-value) + ((and ('system-error _ ...) args) + (let ((errno (system-error-errno args))) + (if (member errno (list ECONNRESET ECONNABORTED ECONNREFUSED)) + (let ((details (call-with-output-string + (lambda (port) + (print-exception port #f (car args) + (cdr args)))))) + (warning (G_ "~a: ~a~%") message details) + error-value) + (apply throw args)))) + ((and ('%exception exception) + (http-get-error? exception)) + (cond + ((and (string-contains (uri->string (http-get-error-uri exception)) + "api.github.com") + (string=3D? (http-get-error-reason exception) + "rate limit exceeded")) + (warning (G_ "GitHub rate limit exceeded"))) + (else + (warning (G_ "~a: HTTP GET error for ~a: ~a (~s)~%") message =2D function (error->string error)) =2D error-value) =2D ((and ('system-error _ ...) args) =2D (let ((errno (system-error-errno args))) =2D (if (member errno (list ECONNRESET ECONNABORTED ECONNREFUSED)) =2D (let ((details (call-with-output-string =2D (lambda (port) =2D (print-exception port #f (car args) =2D (cdr args)))))) =2D (warning (G_ "~a: ~a~%") message details) =2D error-value) =2D (apply throw args)))) =2D (args =2D (apply throw args)))))) + (uri->string (http-get-error-uri exception)) + (http-get-error-code exception) + (http-get-error-reason exception)))) + error-value) + (args + (apply throw args))))) =20 (define-syntax-rule (with-networking-fail-safe message error-value exp ...) (call-with-networking-fail-safe message error-value base-commit: 6718fe7e872e78f8f15dd596fcf15c594a039bfe =2D-=20 2.33.1 --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJJBAEBCAAzFiEEAVhh4yyK5+SEykIzrPUJmaL7XHkFAmHCDBQVHHB1YmxpY0B5 b2N0b2NlbGwueHl6AAoJEKz1CZmi+1x52w0P/j8NKqkIe4LASba9xKOtajkPqmnX bSEN/Uu0rQdOPSuFdsNEZxPEOva4EQsDVj0tgatq9dfq7fXMQ340U/OGsCvyqnce 3cwhpEAV/15nQ1UK1nw9oSDB83T2JxKpy+Gbw17LEp58LqCXduNt6h+jGwTlArmv NMmZWd32+dNiCbqHZeIJ5LBIpFfi1DGvdBiO8ijUGryhF/4IR7sf9jrHV/GixRje dd7P2S7p46e+030/iC6ZD7UGikKUi01+cQIo8wYIHI8Mm0AYiOnnPWd4W9tSi3RP e59fl36G3fgxAWnj1xxQba7V/dOrzRAk3FWp+3DT+n1cHF8nstBLVJy4CPsouyQk NmfWnjC2vKAzbLy4PCeAs6Fwbv9iwxdAOcrLkh8J7YBdOf4tWs+mIbbtDVXOiyws LYUFuRWEpFV30JintJHjcTtCP7pkRYTKvgR0RQFjE/sbCfjkaOfg0HZDWMB5p6ax jyJb+l1OHK6CloOAvSuIsrxjSiqYANXSI9rm4Yan9kCD3AsD8PVLp7RxE/O1oqEO Dgaie+BaH0KVlV+OGAMDaViq0wbJlD8qo2UUP9prtIK7R1oBDjh78Yo2RFRJnrKm koKUbxDaag9LIB48Sdkk+TBBGkbKU/04RXNOwu2W89TdGMcFlyhNHtsJEU9yzpVG INX5OGLKMMepYR+8 =bA40 -----END PGP SIGNATURE----- --==-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 21 12:33:04 2021 Received: (at 52577) by debbugs.gnu.org; 21 Dec 2021 17:33:04 +0000 Received: from localhost ([127.0.0.1]:55460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzj0a-0005cH-6o for submit@debbugs.gnu.org; Tue, 21 Dec 2021 12:33:04 -0500 Received: from andre.telenet-ops.be ([195.130.132.53]:59744) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzj0W-0005bh-TH for 52577@debbugs.gnu.org; Tue, 21 Dec 2021 12:33:03 -0500 Received: from ptr-bvsjgyhxw7psv60dyze.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:3c5f:2eff:feb0:ba5a]) by andre.telenet-ops.be with bizsmtp id Z5Yy2600X4UW6Th015YyF5; Tue, 21 Dec 2021 18:32:59 +0100 Message-ID: Subject: Re: bug#52577: =?UTF-8?Q?=E2=80=98guix?= =?UTF-8?Q?_lint=E2=80=99?= throws an ugly backtrace if the GitHub updater receives =?UTF-8?Q?=E2=80=9Crate?= limit =?UTF-8?Q?exceeded=E2=80=9D?= error From: Maxime Devos To: Xinglu Chen , 52577@debbugs.gnu.org Date: Tue, 21 Dec 2021 17:32:58 +0000 In-Reply-To: <87wnjxev3f.fsf@yoctocell.xyz> References: <87bl1fjpl3.fsf@disroot.org> <746d29cab94d0a8686283a896cd2f639523e9d5d.camel@telenet.be> <87sfurhru8.fsf@disroot.org> <80e40710ed0814ecded0d7f153d1e1ef6e30a311.camel@telenet.be> <87wnjxev3f.fsf@yoctocell.xyz> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r21; t=1640107979; bh=ECWRqunCBDjLJyN2ykgjsvNDuD9TfIfSfenqT4F3jPs=; h=Subject:From:To:Date:In-Reply-To:References; b=Kkbgovj25frtZaITAmU+CYKL916NIpajAKvvQ+mB98dCu7p/+DIECoEku3VDXm5hw RucI/bq2y05U80H0S0oNCXP8VSJglZhvVipXJqxchedIoHOEkDQJe3W7x5ao4LUnkw OOb1UfE8cDXYeFlmZBgcK5kW//WWb1MQULLBsogyfw8A1GyoV7qg058dyb1bAk0j+M 4K3G4oYBDwZfBfhm5CQN+UaakCpOYCltiz1MxRdH2ByZlIC16mU/P8WBt5pD2qKtMS AtiM88aNKWToFu1AqMkg9kOMnlzqgmp/Mw2iH9ZXKweKd75gM8YTymQZP70gWzoJbl /3mkL5sez9UnQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 52577 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Xinglu Chen schreef op di 21-12-2021 om 18:17 [+0100]: > O[...] > Yeah, the catch/throw system doesn’t really work well with ‘raise’. > Here is what I found after some digging: [...] My point was that a raise-style exception shouldn't be wrapped in a (%exception ...) and then again in an &exception-with-kind-and-args, this wrapping should ‘collapse’. Seems like a bug in Guile. Anyway, your patch to Guix looks reasonable to me, though it would be a good idea to look into fixing the double-wrapping in Guile. Greetings, Maxime. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 21 16:49:35 2021 Received: (at 52577) by debbugs.gnu.org; 21 Dec 2021 21:49:35 +0000 Received: from localhost ([127.0.0.1]:55892 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzn0o-0004Ii-V0 for submit@debbugs.gnu.org; Tue, 21 Dec 2021 16:49:35 -0500 Received: from h87-96-130-155.cust.a3fiber.se ([87.96.130.155]:37368 helo=mail.yoctocell.xyz) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzn0j-0004Hz-74 for 52577@debbugs.gnu.org; Tue, 21 Dec 2021 16:49:33 -0500 From: Xinglu Chen DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yoctocell.xyz; s=mail; t=1640123361; bh=XxmzAMVHEdtijXrA41MHkYRMGUgXPEtu2nfpypaDWBA=; h=From:To:Subject:In-Reply-To:References:Date; b=i3xKCGYK/gKauUFpjhcwOeCwiTZCZH9prgmPg4TKsgM3hbgf0dGgDqB/i0XK7Cd7C g9SAoIWfcWh/3Awlj6URIW+scGlQLFLPEKxs6dEeP7YGQHhl8yffDimtVx3NEWXG5/ PCW71kVUb7NaOnvR9tJRklHeMy2lbaXxm4rr+BYg= To: Maxime Devos , 52577@debbugs.gnu.org Subject: Re: bug#52577: =?utf-8?B?4oCYZ3VpeCBsaW504oCZ?= throws an ugly backtrace if the GitHub updater receives =?utf-8?Q?=E2=80=9Crate?= limit =?utf-8?Q?exceeded?= =?utf-8?Q?=E2=80=9D?= error In-Reply-To: References: <87bl1fjpl3.fsf@disroot.org> <746d29cab94d0a8686283a896cd2f639523e9d5d.camel@telenet.be> <87sfurhru8.fsf@disroot.org> <80e40710ed0814ecded0d7f153d1e1ef6e30a311.camel@telenet.be> <87wnjxev3f.fsf@yoctocell.xyz> Date: Tue, 21 Dec 2021 22:49:20 +0100 Message-ID: <878rwdy6fz.fsf@yoctocell.xyz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Spam-Score: 2.9 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Tue, Dec 21 2021, Maxime Devos wrote: > Xinglu Chen schreef op di 21-12-2021 om 18:17 [+0100]: >> O[...] >> Yeah, the catch/throw system doesn’t really work well with ‘raise’. >> Here is what I found after some digging: [...] > > My [...] Content analysis details: (2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: yoctocell.xyz (xyz)] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD 0.4 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS 0.0 PDS_RDNS_DYNAMIC_FP RDNS_DYNAMIC with FP steps X-Debbugs-Envelope-To: 52577 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.9 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Tue, Dec 21 2021, Maxime Devos wrote: > Xinglu Chen schreef op di 21-12-2021 om 18:17 [+0100]: >> O[...] >> Yeah, the catch/throw system doesn’t really work well with ‘raise’. >> Here is what I found after some digging: [...] > > My [...] Content analysis details: (2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: yoctocell.xyz (xyz)] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD 0.4 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS 1.0 BULK_RE_SUSP_NTLD Precedence bulk and RE: from a suspicious TLD -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager 0.0 PDS_RDNS_DYNAMIC_FP RDNS_DYNAMIC with FP steps --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 21 2021, Maxime Devos wrote: > Xinglu Chen schreef op di 21-12-2021 om 18:17 [+0100]: >> O[...] >> Yeah, the catch/throw system doesn=E2=80=99t really work well with =E2= =80=98raise=E2=80=99. >> Here is what I found after some digging: [...] > > My point was that a raise-style exception shouldn't be wrapped in a > (%exception ...) and then again in an &exception-with-kind-and-args, > this wrapping should =E2=80=98collapse=E2=80=99. Seems like a bug in Guil= e. OK, thanks for the clarification. > Anyway, your patch to Guix looks reasonable to me, though it would be a > good idea to look into fixing the double-wrapping in Guile. Cool, fixing the issue in Guile itself would be great, I might look into it in the future. :-) --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJJBAEBCAAzFiEEAVhh4yyK5+SEykIzrPUJmaL7XHkFAmHCS+AVHHB1YmxpY0B5 b2N0b2NlbGwueHl6AAoJEKz1CZmi+1x50eUP/3u8zX5z9eHOs7ajFI9xbhJm9T7K rg2blit3OyVXla70WqFp1IYiw8c1Xl7WsPtqH4rqX7rVtF9oIuyVa3cDEIQ7cBiN 5eOMMcg+p5ZaxgOytyYoaAS53evjD73linyeoXd8Jho1fbu+rpQ8VTLFoFA/LITs QLP79OWc30tfCbih2fD1LAocVYQQEHAxV1Jsomz2RixATjV5IdNcSKZaM5AqtQD2 Qtr4sZ8k1/hYJG33pUFIBBGI5IQfOPxluCGZ89+U1Db2h548fGcF38nioniPGfND 8IBjeEGgqvuWiw0NHG7UfNNBX+Y4zBx0TYBYRZO7kSkqmsOkjwf+NOrqyLZOKeuU QoCYvhD9B1LICqsq/cPDaNIXyivcui5FQ3sv5MId2Hm9TQ++ciu7SCIMpUFZ2UZV 67BPn+Z1t5maFmSYLBRW2lMMHfQzdO+MWIHX3+lsagyiZfLiAuzpmMmgnnV5kM1U bd+Vy8v/7BGcZWFocV+9AD3PhBOiLNvi+Gek9VH8YYMuT8eIkl/LQ3TR17W1TO4Q vH2mmaIdI5+g7tnSq8rrE3ob5p1m6ZBHUr/9OHpblINE7sxC1279Kn4yZCcqUTHv sDThV9/fUFmNuwaqtQMBFpF2+Kc6Yjqq7N+nnS4RV42I5HqzCmld0NM85VcM9pkk TGzE6HhL1BUBXrfx =tdl0 -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 11 17:21:02 2022 Received: (at control) by debbugs.gnu.org; 11 Mar 2022 22:21:02 +0000 Received: from localhost ([127.0.0.1]:38607 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nSnd8-0005GY-5L for submit@debbugs.gnu.org; Fri, 11 Mar 2022 17:21:02 -0500 Received: from eggs.gnu.org ([209.51.188.92]:51372) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nSnd7-0005Fu-6r for control@debbugs.gnu.org; Fri, 11 Mar 2022 17:21:01 -0500 Received: from [2001:470:142:3::e] (port=34248 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nSnd2-0004yY-0y for control@debbugs.gnu.org; Fri, 11 Mar 2022 17:20:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:Subject:From:To:Date:in-reply-to: references; bh=67OCJcAAHUNHMKevbYsp0rLFO7cCBbDCdHwGas7JEa8=; b=ksn+xqXDK2IJ+G ZtMmHjGdv3RXPQf/I5pyhWvuCmwUc4za8dlVQrPEsRphac0zNBeNSruQ3tK2SpvtUtDnZH8/svdAz 6hpQ77zLjHqFk0+yIobsxEC7S2X2rnIqhc4RkbPe57Y2Azk3NuKCkSEGxdm3k3M+ICiyBom5cXNjt Siog69TiwE+Z/gJSEGAGZ8tvf2liCzyvU4Pit2/TYxDlW2zB7AdqFXuWMdpT1bqY3x1c7YfJKMKHS HdvqmAJIO+hHYcZfVgd/embgVFJRRIUCa06LsHssmJObFA/6LbJEE0a1LCuiTDYkl/L2qwpEbaFcj om0VTMoj6iaG++pdnWbw==; Received: from 91-160-117-201.subs.proxad.net ([91.160.117.201]:60217 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nSnd1-0003I2-Ka for control@debbugs.gnu.org; Fri, 11 Mar 2022 17:20:55 -0500 Date: Fri, 11 Mar 2022 23:20:53 +0100 Message-Id: <878rtgw2pm.fsf@gnu.org> To: control@debbugs.gnu.org From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: control message for bug #52577 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) severity 52577 important quit From debbugs-submit-bounces@debbugs.gnu.org Sat May 14 10:18:36 2022 Received: (at 52577-done) by debbugs.gnu.org; 14 May 2022 14:18:36 +0000 Received: from localhost ([127.0.0.1]:47196 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1npsbL-00009x-QS for submit@debbugs.gnu.org; Sat, 14 May 2022 10:18:36 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42976) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1npsbK-00009i-PN for 52577-done@debbugs.gnu.org; Sat, 14 May 2022 10:18:35 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55578) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1npsbE-0002Vv-Tg; Sat, 14 May 2022 10:18:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=1q5/dHdfwDzfyN+R0Xari/7fuJIwZ2S3X0M+4kx9kKI=; b=NDzNJlDEDaEjCUNXIMNt azS7N0ybDN2s0iT253l/KwTy12B4UcL0kH6qkC2Gyej2ViDmjhOs4bpLo6AsK8MGogsmcvBx/Dvw5 36AyxWateoWwKiS01O5wfipUSiEXobFJr4tz2CMpqUnGZoGp+w3LjVAD1MjfvX/j2QyPsrVZ8Nruh ufdtiLFQHIyoS9tB3OpuTS++iQfWe00Lh300YuFHoP3jYgW+lsg38WRTcgsAho54fnkZEXbgq7fjp CozTlQOrhSUyNPXp8ZpuBbJtGXm1ZWNaKrISS94a3f5Vm77wxZ7krFckL7dHH/zGa5XvkBvTCcSPj ZRZdbEeZELH7aA==; Received: from 91-160-117-201.subs.proxad.net ([91.160.117.201]:59841 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1npsbE-0000FA-3g; Sat, 14 May 2022 10:18:28 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Xinglu Chen Subject: Re: bug#52577: =?utf-8?B?4oCYZ3VpeCBsaW504oCZ?= throws an ugly backtrace if the GitHub updater receives =?utf-8?Q?=E2=80=9Crate?= limit =?utf-8?Q?exceeded?= =?utf-8?Q?=E2=80=9D?= error References: <87bl1fjpl3.fsf@disroot.org> Date: Sat, 14 May 2022 16:18:26 +0200 In-Reply-To: <87bl1fjpl3.fsf@disroot.org> (Xinglu Chen's message of "Fri, 17 Dec 2021 15:03:36 +0100") Message-ID: <87v8u8fb9p.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 52577-done Cc: 52577-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hi, Xinglu Chen skribis: > When running =E2=80=98guix lint -c refresh=E2=80=99 on a package hosted o= n GitHub, I get > an ugly backtrace when the GitHub rate limit has been reached. > > $ guix lint pipewire [...] > 1428:5 5 (check-for-updates #) > 771:2 4 (call-with-networking-fail-safe _ _ _) > In ice-9/boot-9.scm: > 1752:10 3 (with-exception-handler _ _ #:unwind? _ # _) > 1685:16 2 (raise-exception _ #:continuable? _) > 1683:16 1 (raise-exception _ #:continuable? _) > 1685:16 0 (raise-exception _ #:continuable? _) > > ice-9/boot-9.scm:1685:16: In procedure raise-exception: > ERROR: > 1. &http-get-error: > uri: #< scheme: https userinfo: #f host: "api.github.com" port= : #f path: "/repos/PipeWire/pipewire/releases" query: #f fragment: #f> > code: 403 > reason: "rate limit exceeded" > 2. &message: "https://api.github.com/repos/PipeWire/pipewire/releases: = HTTP download failed: 403 (\"rate limit exceeded\")" This was fixed in March with commit 55e8e283ae398cc476e50e822383797c5f43db4c. Closing! Ludo=E2=80=99. From unknown Sun Aug 17 01:22:06 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 12 Jun 2022 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator