‘guix lint’ throws an ugly backtrace if the GitHub updater receives “rate limit exceeded” error

  • Done
  • quality assurance status badge
Details
3 participants
  • Ludovic Courtès
  • Maxime Devos
  • Xinglu Chen
Owner
unassigned
Submitted by
Xinglu Chen
Severity
important
X
X
Xinglu Chen wrote on 17 Dec 2021 15:03
‘guix lint’ throws an ugly backtrace if the GitHub updater receives “rate limit exceeded” error
(address . bug-guix@gnu.org)
87bl1fjpl3.fsf@disroot.org
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.

Toggle snippet (39 lines)
$ 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…")
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…> …)
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…> …)
In guix/scripts/lint.scm:
74:21 6 (_ _)
In guix/lint.scm:
1428:5 5 (check-for-updates #<package pipewire@0.3.29 gnu/packag…>)
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: HTTP download failed: 403 (\"rate limit exceeded\")"

When running ‘guix refresh’, a much friendlier error message is produced.

Toggle snippet (4 lines)
$ guix refresh -t github
guix refresh: error: https://api.github.com/repos/OpenZWave/open-zwave/releases: HTTP download failed: 403 ("rate limit exceeded")

The problem seems to be that the ‘check-for-updates’ procedure in (guix
lint) doesn’t catch the ‘&http-get-error’. I tried adding the following
form:

Toggle snippet (8 lines)
(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 ...))

but it doesn’t work. C seems to be something a lot more complicated
than just a ‘&http-get-error’:

Toggle snippet (3 lines)
#<&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\")">)>)>)>

Any ideas on how to extract to the ‘&http-get-error’?
-----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-----

M
M
Maxime Devos wrote on 17 Dec 2021 17:29
Re: bug#52577: ‘guix lint’ throws an ugly backtrace if the GitHub updater receives “rate limit exceeded” error
746d29cab94d0a8686283a896cd2f639523e9d5d.camel@telenet.be
Xinglu Chen schreef op vr 17-12-2021 om 15:03 [+0100]:
Toggle quote (7 lines)
> (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.
M
M
Maxime Devos wrote on 19 Dec 2021 12:58
80e40710ed0814ecded0d7f153d1e1ef6e30a311.camel@telenet.be
Xinglu Chen schreef op vr 17-12-2021 om 21:57 [+0100]:
Toggle quote (59 lines)
> 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
X
X
Xinglu Chen wrote on 21 Dec 2021 18:17
Re: bug#52577: ‘guix lint’ throws an ugly backtrace if the GitHub updater receives “rate limit exceeded ” error
87wnjxev3f.fsf@yoctocell.xyz
On So, Dez 19 2021, Maxime Devos wrote:

Toggle quote (72 lines)
> 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.

Yeah, the catch/throw system doesn’t really work well with ‘raise’.
Here is what I found after some digging:

(catch KIND THUNK HANDLER) uses ‘exception-kind’ to determine the kind
of the exception. Since ‘&http-get-error’ was created using ‘raise’, it
doesn’t really have a notion of a “kind”, therefore, ‘exception-kind’
returns the ‘%exception’ symbol. I guess that’s why I had to match on
('%exception exception) to match the ‘&http-get-error’

Excerpt from the patch I attached:

(catch #t
proc
(match-lambda*
...
((and ('%exception exception)
(http-get-error? exception))
...)
...))
From cf1f08ba8f4c9866ab0077cc50941133ba4ff77b Mon Sep 17 00:00:00 2001
Message-Id: <cf1f08ba8f4c9866ab0077cc50941133ba4ff77b.1639773195.git.public@yoctocell.xyz>
From: Xinglu Chen <public@yoctocell.xyz>
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=UTF-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 seems
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.

---
guix/lint.scm | 80 ++++++++++++++++++++++++++++-----------------------
1 file changed, 44 insertions(+), 36 deletions(-)

Toggle diff (96 lines)
diff --git a/guix/lint.scm b/guix/lint.scm
index 403f343b6c..67b2bb7221 100644
--- 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."
- (guard (c ((http-get-error? c)
- (warning (G_ "~a: HTTP GET error for ~a: ~a (~s)~%")
- message
- (uri->string (http-get-error-uri c))
- (http-get-error-code c)
- (http-get-error-reason c))
- error-value))
- (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~%")
+ (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=? (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
- 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))))
- (args
- (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)))))
(define-syntax-rule (with-networking-fail-safe message error-value exp ...)
(call-with-networking-fail-safe message error-value

base-commit: 6718fe7e872e78f8f15dd596fcf15c594a039bfe
--
2.33.1
-----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-----

M
M
Maxime Devos wrote on 21 Dec 2021 18:32
Re: bug#52577: ‘guix lint’ throws an ugly backtrace if the GitHub updater receives “rate limit exceeded” error
c1d5275a6668fa6fca16eb6707091deb67905ab3.camel@telenet.be
Xinglu Chen schreef op di 21-12-2021 om 18:17 [+0100]:
Toggle quote (4 lines)
> 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.
X
X
Xinglu Chen wrote on 21 Dec 2021 22:49
Re: bug#52577: ‘guix lint’ throws an ugly backtrace if the GitHub updater receives “rate limit exceeded ” error
878rwdy6fz.fsf@yoctocell.xyz
On Tue, Dec 21 2021, Maxime Devos wrote:

Toggle quote (9 lines)
> 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.

OK, thanks for the clarification.

Toggle quote (3 lines)
> 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. :-)
-----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-----

L
L
Ludovic Courtès wrote on 11 Mar 2022 23:20
control message for bug #52577
(address . control@debbugs.gnu.org)
878rtgw2pm.fsf@gnu.org
severity 52577 important
quit
L
L
Ludovic Courtès wrote on 14 May 2022 16:18
Re: bug#52577: ‘guix lint’ throws an ugly backtrace if the GitHub updater receives “rate limit exceeded ” error
(name . Xinglu Chen)(address . public@yoctocell.xyz)(address . 52577-done@debbugs.gnu.org)
87v8u8fb9p.fsf@gnu.org
Hi,

Xinglu Chen <public@yoctocell.xyz> skribis:

Toggle quote (5 lines)
> 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.
>
> $ guix lint pipewire

[...]

Toggle quote (16 lines)
> 1428:5 5 (check-for-updates #<package pipewire@0.3.29 gnu/packag…>)
> 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: HTTP download failed: 403 (\"rate limit exceeded\")"

This was fixed in March with commit
55e8e283ae398cc476e50e822383797c5f43db4c.

Closing!

Ludo’.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 52577@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 52577
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch