bug#43985: Error logging in with non-Latin language
After installing Guix system in non-Latin language, it is not possible to log in. When installing the system, the Guix system user login password was a "Persian" password; Once installed, the login page with my password will not open. (This is not a password error) To install on another system, I set an English password when installing, it worked properly and I logged in.
bug#31302: `guix import json` doesn't handle inputs with the form 'package:output'
I just checked this and failed to replicate it. It happily generates config from `glib:doc', `glib:bin' and `glib:out' in input fields and complains if there's a nonexistent `glib:foo' input, as of v1.1.0. -- Lulu
bug#39434: [PATCH] gnu: Fix typo in symbol exported from (gnu services web)
diff --git a/gnu/services/web.scm b/gnu/services/web.scm index c8ffc19d83..b2d1dcf0ee 100644 --- a/gnu/services/web.scm +++ b/gnu/services/web.scm @@ -90,7 +90,7 @@ nginx-configuration nginx-configuration? -nginx-configuartion-nginx +nginx-configuration-nginx nginx-configuration-log-directory nginx-configuration-run-directory nginx-configuration-server-blocks
bug#43986: core-updates' grep and coreutils fail strerror_r and perror2 tests in gnulib-tests on armhf-on-aarch64
Hi, core-updates' grep and coreutils fail strerror_r and perror2 tests in gnulib-tests on armhf-on-aarch64: guix-build-coreutils-8.32.drv-0: test-perror2.c:84: assertion 'msg3 == msg4 || STREQ (msg3, str3)' failed test-strerror_r.c:170: assertion 'msg3 == msg4 || STREQ (msg3, str3)' failed (on dover.guix.info) grep-3.4: test-perror2.c:84: assertion 'msg3 == msg4 || STREQ (msg3, str3)' failed test-strerror_r.c:170: assertion 'msg3 == msg4 || STREQ (msg3, str3)' failed pgpx5FsmK19yG.pgp Description: OpenPGP digital signature
bug#39434: [PATCH] gnu: Fix typo in symbol exported from (gnu services web)
Le Wed, 14 Oct 2020 09:37:30 +0300 (TRT), Lulu a écrit : > diff --git a/gnu/services/web.scm b/gnu/services/web.scm > index c8ffc19d83..b2d1dcf0ee 100644 > --- a/gnu/services/web.scm > +++ b/gnu/services/web.scm > @@ -90,7 +90,7 @@ > > nginx-configuration > nginx-configuration? > -nginx-configuartion-nginx > +nginx-configuration-nginx > nginx-configuration-log-directory > nginx-configuration-run-directory > nginx-configuration-server-blocks > > > Thank you! Pushed as 5436b673f53d27753b53ab8d94eea6153a20e483 to master with small changes to the commit message.
bug#43486: guix pull raised a bug in 679d5e6b3d
On Tue, Oct 13, 2020 at 01:11:40AM +0800, Nala Ginrut wrote: > > Leo Famulari writes: > > > If that's the case, it would be useful to know how much RAM was > > available to the system. > > This bug has gone from my system, I've run `guix pull` each day since > then, they're all ok. But I'd like to answer your question: 16G RAM + 18G > swap. Okay. I'll close the bug for now. Feel free to re-open it if the problem happens again. signature.asc Description: PGP signature
bug#43985: Error logging in with non-Latin language
On Wed, 14 Oct 2020 06:37:32 +0200 (CEST) soheilkhanalipur--- via Bug reports for GNU Guix wrote: > After installing Guix system in non-Latin language, it is not > possible to log in. When installing the system, the Guix system user > login password was a "Persian" password; Once installed, the login > page with my password will not open. (This is not a password error) > To install on another system, I set an English password when > installing, it worked properly and I logged in. Does the installer use the same layout as the installed system? That's usually what leads to these problems. I've had the same issue a long time ago on Arch with Hungarian passwords. Personally, I avoid passwords that can't be typed with ASCII, because I might have to log in from someone else's machine and ASCII is the lowest common denominator, for better or worse.
bug#43850: cuirass: inconsistent SQL queries execution time.
Hello, I pushed and deployed several patches that: - update metrics in a single transaction - register builds in a single transaction - use a single write database worker, queuing queries and submitting them by batches (in a single transaction). - optimize some SQLite parameters (decrease WAL size, use more RAM caching) this should improve the situation, even if I still observe some inconsistent execution duration. I still have a few improvement ideas such as pre-allocating a large database file to decrease fragmentation and running periodic vacuums. Thanks, Mathieu
bug#43985: comment
>From the beginning of the operating system installation process, I chose >Persian; Just to write the host name, I changed the language to English using >Alt + Shift.
bug#43985: Error logging in with non-Latin language
>From the beginning of the operating system installation process, I chose >Persian; Just to write the host name, I changed the language to English using >Alt + Shift.
bug#44000: Guile-Git cross-compiled to i586-pc-gnu gets bytestructures wrong
Hello!
You might have seen that ‘guix pull’ doesn’t work in your childhurd:
--8<---cut here---start->8---
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
guix pull: error: Git error: invalid version 0 on git_proxy_options
--8<---cut here---end--->8---
This is due to an ABI breakage whereby the Guile-Git code
(cross-compiled from x86_64-linux) fills in the ‘fetch_opts’ member of
‘git_clone options’ offset by one word.
On closer inspection, the problem is:
--8<---cut here---start->8---
scheme@(git structs)> (bytestructure-descriptor-size (bs:struct `(("x"
,(bs:pointer uint8)) ("y" ,size_t
$20 = 12
scheme@(git structs)> %host-type
$21 = "i586-pc-gnu"
--8<---cut here---end--->8---
Compare with the correct answer:
--8<---cut here---start->8---
$ guix environment --ad-hoc -C -s i686-linux guile guile-bytestructures --
guile
[...]
scheme@(guile-user)> ,use(bytestructures guile)
scheme@(guile-user)> %host-type
$1 = "i686-unknown-linux-gnu"
scheme@(guile-user)> (bytestructure-descriptor-size (bs:struct `(("x"
,(bs:pointer uint8))("y" ,size_t
$2 = 8
--8<---cut here---end--->8---
More specifically, the size of ‘size_t’ is wrong, but pointer size is
right:
--8<---cut here---start->8---
scheme@(git structs)> (bytestructure-descriptor-size size_t)
$27 = 8
scheme@(git structs)> (bytestructure-descriptor-size uintptr_t )
$28 = 8
scheme@(git structs)> (bytestructure-descriptor-size (bs:pointer uint8))
$29 = 4
--8<---cut here---end--->8---
‘numeric.scm’ in bytestructures reads:
--8<---cut here---start->8---
(define arch32bit? (cond-expand
(lp32 #t)
(ilp32 #t)
(else #f)))
;; …
(define uintptr_t (if arch32bit?
uint32
uint64))
(define size_t uintptr_t)
--8<---cut here---end--->8---
But (bytestructures guile numeric-data-model) has this:
--8<---cut here---start->8---
(define data-model
(if (= 4 (sizeof '*))
(if (= 2 (sizeof int))
'lp32
'ilp32)
(cond
((= 8 (sizeof int)) 'ilp64)
((= 4 (sizeof long)) 'llp64)
(else'lp64
(cond-expand-provide
(current-module)
(list architecture data-model))
--8<---cut here---end--->8---
The problem is that the ‘cond-expand’ used to define ‘arch32bit?’ is a
expansion-time thing when (cross-)building Bytestructures itself, so
it’s incorrect from cross-building from 64-bit to 32-bit.
I believe that changing it to:
(define arch32bit? (memq data-model '(ilp32 lp32)))
would fix it because then the test would happen at run time.
(Note that Guile-Git uses only the procedural layer of Bytestructures.
The syntactic layer is likely not cross-compilation-capable for similar
reasons.)
To be continued…
Thanks,
Ludo’.
bug#41058: GNOME Maps fails to start in GNOME
Bumping this, as it has been months since I've posted my fix. For the record, it might also be worth looking into #39324, which uses a different workaround, and seeing whether the dbus service can be patched in a similar manner. Regards, Leo
