GNU bug report logs - #52577
‘guix lint’ throws an ugly backtrace if the GitHub updater receives “rate limit exceeded” error

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: guix; Reported by: Xinglu Chen <public@HIDDEN>; dated Fri, 17 Dec 2021 14:04:01 UTC; Maintainer for guix is bug-guix@HIDDEN.

Message received at 52577 <at> debbugs.gnu.org:


Received: (at 52577) by debbugs.gnu.org; 19 Dec 2021 11:58:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 19 06:58:30 2021
Received: from localhost ([127.0.0.1]:45000 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1myuph-0003Bd-Sc
	for submit <at> 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 <maximedevos@HIDDEN>) id 1myupf-0003BE-ES
 for 52577 <at> 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@HIDDEN>
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 <maximedevos@HIDDEN>
To: Xinglu Chen <public@HIDDEN>, 52577 <at> debbugs.gnu.org
Date: Sun, 19 Dec 2021 11:58:25 +0000
In-Reply-To: <87sfurhru8.fsf@HIDDEN>
References: <87bl1fjpl3.fsf@HIDDEN>
 <746d29cab94d0a8686283a896cd2f639523e9d5d.camel@HIDDEN>
 <87sfurhru8.fsf@HIDDEN>
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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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:
> #<<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: #<<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: #<<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





Information forwarded to bug-guix@HIDDEN:
bug#52577; Package guix. Full text available.

Message received at 52577 <at> debbugs.gnu.org:


Received: (at 52577) by debbugs.gnu.org; 17 Dec 2021 16:29:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Dec 17 11:29:42 2021
Received: from localhost ([127.0.0.1]:40506 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1myG74-00033i-Li
	for submit <at> 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 <maximedevos@HIDDEN>) id 1myG72-00033Z-87
 for 52577 <at> 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@HIDDEN>
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 <maximedevos@HIDDEN>
To: Xinglu Chen <public@HIDDEN>, 52577 <at> debbugs.gnu.org
Date: Fri, 17 Dec 2021 16:29:35 +0000
In-Reply-To: <87bl1fjpl3.fsf@HIDDEN>
References: <87bl1fjpl3.fsf@HIDDEN>
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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.





Information forwarded to bug-guix@HIDDEN:
bug#52577; Package guix. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 17 Dec 2021 14:03:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Dec 17 09:03:49 2021
Received: from localhost ([127.0.0.1]:38316 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1myDps-0004g4-LJ
	for submit <at> 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 <public@HIDDEN>) id 1myDpr-0004fx-4D
 for submit <at> 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 <public@HIDDEN>)
 id 1myDpp-0003Jd-T8
 for bug-guix@HIDDEN; 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 <public@HIDDEN>)
 id 1myDpn-0002j0-9N
 for bug-guix@HIDDEN; Fri, 17 Dec 2021 09:03:45 -0500
From: Xinglu Chen <public@HIDDEN>
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@HIDDEN
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@HIDDEN>
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@HIDDEN;
 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.
    --8<cut herestart>8--- $ guix lint pipewire fetching CVE database for 2021...
    fetching CVE database for 2018... Backtrace:ipewire@HIDDEN [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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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@HIDDEN [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 #<procedure 7fb8f038ff40 at guix/scripts/lin=E2=80=
=A6> =E2=80=A6)
In guix/scripts/lint.scm:
     65:4  8 (run-checkers _ _ #:store _)
In srfi/srfi-1.scm:
    634:9  7 (for-each #<procedure 7fb8e15a8d20 at guix/scripts/lin=E2=80=
=A6> =E2=80=A6)
In guix/scripts/lint.scm:
    74:21  6 (_ _)
In guix/lint.scm:
   1428:5  5 (check-for-updates #<package pipewire@HIDDEN gnu/packag=E2=80=
=A6>)
    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: #<<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: #<<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: #<<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-----
--=-=-=--




Acknowledgement sent to Xinglu Chen <public@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-guix@HIDDEN. Full text available.
Report forwarded to bug-guix@HIDDEN:
bug#52577; Package guix. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Sun, 19 Dec 2021 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.