Hello Guix!
Upon running `alacritty` in terminal, I get the following error:
Xlib: sequence lost (0x1006f > 0x71) in reply type 0x0!
Xlib: sequence lost (0x10074 > 0x76) in reply type 0x0!
Xlib: sequence lost (0x10079 > 0x7b) in reply type 0x0!
Xlib: sequence lost (0x1007e > 0x80) in reply type
Hi,
Is there any update about this issue?
I receive same "division by zero" error after running cuirass for
a while.
deleting the records with `starttime` equal to 0 from `builds` table,
cuirass could start again. but the issue happens again after a while.
--
Reza Alizadeh Majd
PantherX Te
Hi guilers and guix,
I (and some other people) encountered this bug:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43521#11
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45788
https://issues.guix.gnu.org/48389#8
There is already a fix:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43521#11
App
On Mon, Jul 19, 2021 at 05:34:55AM -0400, Raghav Gururajan wrote:
> Hello Guix!
>
> Upon running `alacritty` in terminal, I get the following error:
>
> Xlib: sequence lost (0x1006f > 0x71) in reply type 0x0!
> Xlib: sequence lost (0x10074 > 0x76) in reply type 0x0!
> Xlib: sequence lost (0x10079
Hi,
Maxime Devos skribis:
> From the package definition of "brdf-explorer":
>
> (format port "#!/bin/sh
> # Run the thing from its home, otherwise it just bails out.
> cd \"~a\"
> exec -a \"$0\" ~a/.brdf-real~%" ...)
>
> That should be #!/gnu/store/.../bin/sh instead ...
No, it’s OK, because th
Hi,
Domagoj Stolfa skribis:
> While running `make check-system`, I've encountered an issue with building
> GnuTLS (see attached drv file).
For posterity, the log looks like this:
--8<---cut here---start->8---
make[5]: Entering directory
'/tmp/guix-build-gnu
Hi:
Thanks for taking a look!
> Could you confirm that it works for you on current ‘master’?
I managed to run it today both on my Guix System and a RHEL box, which would
suggest that it "reproducibly" works :-).
--
Domagoj
signature.asc
Description: PGP signature
Thank you both! I was not aware that this belonged in the firmware
field and not the packages field. This has solved the error message
during boot. Further, adding the kernel argument successfully sets my
region as US on boot.
tags 49611 notabug
close 49611
This is not part of the bug per-say, bu
Katherine Cox-Buday skribis:
> Thank you both! I was not aware that this belonged in the firmware
> field and not the packages field. This has solved the error message
> during boot. Further, adding the kernel argument successfully sets my
> region as US on boot.
>
> tags 49611 notabug
> close 49
