bug#48213: offlineimap build fails

[Bone Baboon via Bug reports for GNU Guix]

Tobias Geerinckx-Rice writes:
> you should report this upstream first

I have reported this to Seth Michael Larson the maintainer of rfc6555.
https://pypi.org/project/rfc6555/

I also asked Seth Michael Larson if the rfc6555 test suite could be
modified so that test_ipv6_available does not fail if IPv6 is disabled.

bug#48214: inetutils-1.9.4 build fails

[Bone Baboon via Bug reports for GNU Guix]

Tobias Geerinckx-Rice writes:
> Bone Baboon via Bug reports for GNU Guix 写道：
>> FAIL: syslogd.sh
>> 
>>
>> ../src/logger: ::1:7041: Cannot assign requested address
>
> Looks like the same cause as :
> missing IPv6 support on the host kernel.

Thank you for pointing this out.

I have reported this to the inetutils bug mailing list and asked if the
inetutils test suite could be modified so that syslogd.sh does not fail
if IPv6 is disabled.

bug#48239: rust-1.19.0 build fails

[Bone Baboon via Bug reports for GNU Guix]

Mark H Weaver writes:
> Are you aware of any relevant customizations to your kernel
> configuration that might possibly be related to this?

The system configuration includes:

```
  (kernel-arguments
   (append
(list
 "nomodeset"
 "ipv6.disable=1")
%default-kernel-arguments))
```

Without "nomodeset" the computer is not able to boot.

"ipv6.disable=1" is to prevent ipv6 leaks from compromising the privacy
provided by a VPN service I am using.

> For what it's worth, on my Thinkpad X200 (Core 2 Duo) with 4 GB of RAM
> and 8 GB of swap, I've been successully building Rust locally using Guix
> for many years, as long as I don't run other memory intensive processes
> at the same time.

That is good to know.

I was able to build the Rust bootstrap chain from source on this
computer before.  It took several days to complete.

> It might be worth trying the build a second time.  Occasionally we see
> nondeterministic build failures in some packages, although I don't
> recall seeing such failures in Rust.

I tried again and got the same error.

bug#47260: Package GNU MediaGoblin as a Guix service

[Ben Sturmfels via Bug reports for GNU Guix]

Thanks for the update Arne. This issue is specifically about Guix
packaging, so to save us losing track of your update, please post it to
the dedicated mediagoblin-de...@gnu.org thread we started a couple of
months back:

https://lists.gnu.org/archive/html/mediagoblin-devel/2021-03/msg00026.html

Thanks again,
Ben

On Wed, 05 May 2021, Arne Babenhauserheide wrote:

> Hi,
>
> I just added non-flickering video-change to the m3u-player. Attaching
> the file. I thought that could be useful for MediaGoblin. The file is
> attached.
>
>
> Best wishes,
> Arne
>
>
> Ben Sturmfels via Bug reports for GNU Guix  writes:
>
>> On Tue, 30 Mar 2021, Ben Sturmfels wrote:
>>
>>> On Fri, 19 Mar 2021, Ben Sturmfels wrote:
>>
 8. Either package RabbitMQ (probably hard) or rewrite MediaGoblin's
 processing backend from Celery/RabbitMQ to RQ/Redis. Celery has been
 implicated in many bugs anyway, so there may benefits to the project to
 doing this anyway.
>>>
>>> I learnt that Celery has a Redis backend, so maybe we don't need to
>>> rewrite just yet.
>>
>> It turns out that MediaGoblin's Celery-based media processing backend
>> work out of the box by simply configuring:
>>
>>   [celery]
>>   BROKER_URL = "redis://"
>>
>> (There seems to be an unrelated bug where media is marked as failed after
>> restarting Celery, possibly tied to sqlite. We've had reports of this
>> with a RabbitMQ broker too though.)
>>
>>
>> This means our shorter to-do list is now:
>>
>> 1. Upstream our new python-soundfile Guix package from guix-env.scm when
>> core-updates is merged.
>>
>> 2. Upstream our upgraded python-wtforms package.
>>
>> 6. Convert MediaGoblin's jQuery-based JavaScript to use vanilla JS.
>> Video and audio are essentially functional without the NPM installed
>> players. Some later refinements perhaps.
>>
>> 4. Package MediaGoblin itself. The build process is ./configure/make
>> which is a bit weird for a Python project.
>>
>> 5. Get a basic Guix service working, with sqlite3 and without the
>> offloaded media transcoding currently using Celery task queue with a
>> Redis broker.
>>
>> 7. Work out why H264 support is missing.
>>
>> 8. Figure out how to deal with translations.
>>
>> 9. Add a PostgreSQL database to the Guix service instead of sqlite3.
>>
>> Regards,
>> Ben

bug#48024: glib-2.62.6 build fails i686

[Bone Baboon via Bug reports for GNU Guix]

Mark H Weaver writes:
>> I was having trouble finding the build log.
>
> Here's one way to find it:
>
> $ cd /var/log/guix/drvs
> $ ls -ltr */*-glib-2* | tail
>
> The very small log files are the result of grafting derivations.
> Look for the most recent one that's more than 1K.
>
> Alternatively, it _might_ work to run:
>
> $ guix build --log-file --file=test-glib.scm

Thank you this is helpful.

bug#48024: glib-2.62.6 build fails i686

[Mark H Weaver]

Hi,

Bone Baboon  writes:

> Efraim Flashner writes:
>> I looked closer at the bug report and I see they are timing out at 60
>> and 180 for Bone Baboon as they currently are.
>>
>> Bone Baboon: Can you build the attached test-glib.scm file and send back
>> the build log? I want to make sure I change the timeout to something
>> long enough.
>>
>> You can build it with 'guix build -f test-glib.scm'
>
> I ran `guix build --file=test-glib.scm` and I was successful.

That's good news!

> I was having trouble finding the build log.

Here's one way to find it:

$ cd /var/log/guix/drvs
$ ls -ltr */*-glib-2* | tail

The very small log files are the result of grafting derivations.
Look for the most recent one that's more than 1K.

Alternatively, it _might_ work to run:

$ guix build --log-file --file=test-glib.scm

Thanks,
  Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#42902: texlive substitute TLS error: decoding the received packet

[Maxim Cournoyer]

Hi!

"Dr. Arne Babenhauserheide"  writes:

> Hi,
>
> I cannot update or re-install texlive:
>
> $ LANG=C guix install texlive
> The following package will be upgraded:
>texlive (dependencies or package changed)
>
> The following derivation will be built:
>/gnu/store/a9ndmp1c8bqaz9s7h6x3k7f4l7qawq7n-texlive-texmf-20190410.drv
> 2845.8 MB will be downloaded
> downloading from 
> https://ci.guix.gnu.org/nar/lzip/z4xvgiliw5baf1pr4z03c7n2hw3bm5x5-texlive-texmf-20190410
>  ...
>  texlive-texmf-20190410  2.61GiB  
>   3.3MiB/s 00:02 [
>   ]   0.2%guix substitute: error: TLS error in procedure 
> 'read_from_session_record_port': Error decoding the received TLS packet.
> substitution of 
> /gnu/store/z4xvgiliw5baf1pr4z03c7n2hw3bm5x5-texlive-texmf-20190410 failed
> guix install: error: some substitutes for the outputs of derivation 
> `/gnu/store/v5arvb6lqg86gc2lsnmyfi1bj74yzx7f-texlive-20190410.drv' failed 
> (usually happens due to networking issues); try `--fallback' to build 
> derivation from source
>
> Best wishes,
> Arne

I've just encountered that error message, trying to update my profile:

guix substitute: error: TLS error in procedure 'read_from_session_record_port': 
Error decoding the received TLS packet.
substitution of 
/gnu/store/jxzydj6zvpxfxfgv66010sa7dsnqci76-adwaita-icon-theme-3.34.3 failed
guix package: error: corrupt input while restoring archive from socket

The daemon in use is this:
/gnu/store/rsya5hkyq3fixl2r36lq2g892jadq1fc-guix-1.2.0-21.4dff6ec/bin/guix-daemon.
My system was updated a bit more than a week ago.

Maxim

bug#48240: [PATCH 4/4] ssh: Honor GUIX_DAEMON_SOCKET on the target machine.

[Ludovic Courtès]

Fixes .
Reported by Ricardo Wurmus .

* guix/ssh.scm (remote-daemon-channel)[redirect]: Define
'connect-to-daemon'.  Use the same-named procedure from (guix store)
when available, and honor GUIX_DAEMON_SOCKET.
---
 guix/ssh.scm | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/guix/ssh.scm b/guix/ssh.scm
index b39b90f733..77a9732ce5 100644
--- a/guix/ssh.scm
+++ b/guix/ssh.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2016, 2017, 2018, 2019, 2020 Ludovic Courtès 
+;;; Copyright © 2016, 2017, 2018, 2019, 2020, 2021, 2021 Ludovic Courtès 

 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -253,7 +253,22 @@ EXP never returns or calls 'primitive-exit' when it's 
done."
(use-modules (ice-9 match) (rnrs io ports)
 (rnrs bytevectors))
 
-   (let ((sock(socket AF_UNIX SOCK_STREAM 0))
+   (define connect-to-daemon
+ ;; XXX: 'connect-to-daemon' used to be private and before that it
+ ;; didn't even exist, hence these shenanigans.
+ (let ((connect-to-daemon
+(false-if-exception (module-ref (resolve-module '(guix store))
+'connect-to-daemon
+   (lambda (uri)
+ (if connect-to-daemon
+ (connect-to-daemon uri)
+ (let ((sock (socket AF_UNIX SOCK_STREAM 0)))
+   (connect sock AF_UNIX ,socket-name)
+   sock)
+
+   ;; Use 'connect-to-daemon' to honor GUIX_DAEMON_SOCKET.
+   (let ((sock(connect-to-daemon (or (getenv "GUIX_DAEMON_SOCKET")
+ socket-name)))
  (stdin   (current-input-port))
  (stdout  (current-output-port))
  (select* (lambda (read write except)
@@ -272,8 +287,6 @@ EXP never returns or calls 'primitive-exit' when it's done."
  (setvbuf stdin 'block 65536)
  (setvbuf sock 'block 65536)
 
- (connect sock AF_UNIX ,socket-name)
-
  (let loop ()
(match (select* (list stdin sock) '() '())
  ((reads () ())
-- 
2.31.1

bug#48240: [PATCH 1/4] store: 'open-connection' never returns #f.

[Ludovic Courtès]

* guix/store.scm (open-connection)[handshake-error]: New procedure.
Call it in code paths that would previously return #f.
---
 guix/store.scm | 66 +++---
 1 file changed, 36 insertions(+), 30 deletions(-)

diff --git a/guix/store.scm b/guix/store.scm
index 37ae6cfedd..315ae4cdce 100644
--- a/guix/store.scm
+++ b/guix/store.scm
@@ -548,13 +548,16 @@ space on the file system so that the garbage collector 
can still operate,
 should the disk become full.  When CPU-AFFINITY is true, it must be an integer
 corresponding to an OS-level CPU number to which the daemon's worker process
 for this connection will be pinned.  Return a server object."
+  (define (handshake-error)
+(raise (condition
+( (file (or port uri))
+ (errno EPROTO))
+( (message "build daemon handshake failed")
+
   (guard (c ((nar-error? c)
  ;; One of the 'write-' or 'read-' calls below failed, but this is
  ;; really a connection error.
- (raise (condition
- ( (file (or port uri))
-  (errno EPROTO))
- ( (message "build daemon handshake failed"))
+ (handshake-error)))
 (let*-values (((port)
(or port (connect-to-daemon uri)))
   ((output flush)
@@ -562,32 +565,35 @@ for this connection will be pinned.  Return a server 
object."
   (make-bytevector 8192
   (write-int %worker-magic-1 port)
   (let ((r (read-int port)))
-(and (= r %worker-magic-2)
- (let ((v (read-int port)))
-   (and (= (protocol-major %protocol-version)
-   (protocol-major v))
-(begin
-  (write-int %protocol-version port)
-  (when (>= (protocol-minor v) 14)
-(write-int (if cpu-affinity 1 0) port)
-(when cpu-affinity
-  (write-int cpu-affinity port)))
-  (when (>= (protocol-minor v) 11)
-(write-int (if reserve-space? 1 0) port))
-  (letrec* ((built-in-builders
- (delay (%built-in-builders conn)))
-(conn
- (%make-store-connection port
- (protocol-major v)
- (protocol-minor v)
- output flush
- (make-hash-table 100)
- (make-hash-table 100)
- vlist-null
- built-in-builders)))
-(let loop ((done? (process-stderr conn)))
-  (or done? (process-stderr conn)))
-conn)
+(unless (= r %worker-magic-2)
+  (handshake-error))
+
+(let ((v (read-int port)))
+  (unless (= (protocol-major %protocol-version)
+ (protocol-major v))
+(handshake-error))
+
+  (write-int %protocol-version port)
+  (when (>= (protocol-minor v) 14)
+(write-int (if cpu-affinity 1 0) port)
+(when cpu-affinity
+  (write-int cpu-affinity port)))
+  (when (>= (protocol-minor v) 11)
+(write-int (if reserve-space? 1 0) port))
+  (letrec* ((built-in-builders
+ (delay (%built-in-builders conn)))
+(conn
+ (%make-store-connection port
+ (protocol-major v)
+ (protocol-minor v)
+ output flush
+ (make-hash-table 100)
+ (make-hash-table 100)
+ vlist-null
+ built-in-builders)))
+(let loop ((done? (process-stderr conn)))
+  (or done? (process-stderr conn)))
+conn))
 
 (define* (port->connection port
#:key (version %protocol-version))
-- 
2.31.1

bug#48240: [PATCH 2/4] ssh: 'connect-to-remote-daemon' raises a nicer message upon error.

[Ludovic Courtès]

* guix/ssh.scm (connect-to-remote-daemon): Catch
'store-connection-error?' and rethrow.
---
 guix/ssh.scm | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/guix/ssh.scm b/guix/ssh.scm
index 457d1890f9..b39b90f733 100644
--- a/guix/ssh.scm
+++ b/guix/ssh.scm
@@ -302,8 +302,13 @@ EXP never returns or calls 'primitive-exit' when it's 
done."
 "/var/guix/daemon-socket/socket"))
   "Connect to the remote build daemon listening on SOCKET-NAME over SESSION,
 an SSH session.  Return a  object."
-  (open-connection #:port (remote-daemon-channel session socket-name)))
-
+  (guard (c ((store-connection-error? c)
+ ;; Raise a more focused error condition.
+ (raise (formatted-message
+ (G_ "failed to connect over SSH to daemon at '~a', socket 
~a")
+ (session-get session 'host)
+ socket-name
+(open-connection #:port (remote-daemon-channel session socket-name
 
 (define (store-import-channel session)
   "Return an output port to which archives to be exported to SESSION's store
-- 
2.31.1

bug#48240: [PATCH 3/4] store: Export 'connect-to-daemon'.

[Ludovic Courtès]

* guix/store.scm (connect-to-daemon): Make public.  Improve docstring.
---
 guix/store.scm | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/guix/store.scm b/guix/store.scm
index 315ae4cdce..9d706ae590 100644
--- a/guix/store.scm
+++ b/guix/store.scm
@@ -90,6 +90,7 @@
 hash-algo
 build-mode
 
+connect-to-daemon
 open-connection
 port->connection
 close-connection
@@ -501,7 +502,10 @@
 
 (define (connect-to-daemon uri)
   "Connect to the daemon at URI, a string that may be an actual URI or a file
-name."
+name, and return an input/output port.
+
+This is a low-level procedure that does not perform the initial handshake with
+the daemon.  Use 'open-connection' for that."
   (define (not-supported)
 (raise (condition (
(file uri)
-- 
2.31.1

bug#48225: Simple workaround

[Sharlatan Hellseher]

Hi,

If chaining  `package-name->name+version` function  may affect a large
layer of infrastructure here is could a quick adhoc workaround:

sbcl-3d-vectors -> sbcl-cl3d-vectors
sbcl-3d-vectors -> sbcl-three-d-vectors
sbcl-3d-vectors -> sbcl-iiid-vectors

Or use any predictable common prefix which could be use and replaced
after the function is reviewed.
-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#48024: glib-2.62.6 build fails i686

[Bone Baboon via Bug reports for GNU Guix]

Efraim Flashner writes:
> I looked closer at the bug report and I see they are timing out at 60
> and 180 for Bone Baboon as they currently are.
>
> Bone Baboon: Can you build the attached test-glib.scm file and send back
> the build log? I want to make sure I change the timeout to something
> long enough.
>
> You can build it with 'guix build -f test-glib.scm'

I ran `guix build --file=test-glib.scm` and I was successful.

I was having trouble finding the build log.

I have instead attached the output of the build command.



build-output.lz
Description: Binary data

bug#46424: Use load-systems or load-systems*

[Sharlatan Hellseher]

Hi I've just checked source of ASDF and it looks like there is a
native option to load multiple systems at once

> --8<---cut here---start->8--->
  (defun load-systems* (systems  keys)
"Loading multiple systems at once."
(dolist (s systems) (apply 'load-system s keys)))

  (defun load-systems ( systems)
"Loading multiple systems at once."
(load-systems* systems))
--8<---cut here---end--->8---

https://gitlab.common-lisp.net/asdf/asdf/-/blob/master/operate.lisp#L155

-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#48146: Getting diverted to non-updated branches: a limitation of the authentication mechanism?

[Ludovic Courtès]

Hi Maxime,

Maxime Devos  skribis:

>   5. The user is at commit A. There is a correctly-signed commit C on, say, 
> core-updates,
>  such that:  C comes after A, but C is not yet in master for the 
> foreseable future.
>
> Method:
>   6. The attacker subverts savannah, replacing the tip of 'master' with 'C'.
>  To avoid detection, this subverted master is only served to the 
> targetted users.
>   7. The targetted users' systems' unattended-service-type
>  do their equivalent of "guix pull && guix system reconfigure ...".
>   8. The targetted systems are now on core-updates, which does not receive 
> timely
>  security updates.
>   9. On future automatic upgrades, the users' systems will stay on 
> core-updates,
>  without any obvious indication something is wrong.  (Aside from 
> recompilations,
>  maybe the user's machine has 40GiB RAM, dozens of processors and sits in 
> some
>  data centre where the user won't notice the sound of the fans.)
>  10. A vulnerability is discovered (and fixed) and there is a blog post or 
> something!
>  The attacker is late to the party.
>  11. Unfortunately for the user, the automatic upgrade does not fix the 
> vulnerability
>  on the user's system, as vulnerabilities are not patched on core-updates.

Note that the attacker doesn’t even need to do something as
sophisticated as you describe: they can just tweak the repo such that
the advertised tip of ‘master’ remains today’s commit for some time.

The blog post Leo mentioned discusses this problem and it’s not
addressed per se.  If specific users are targeted, as in your scenario,
it could be hard to detect.

But then again, I’d argue it’s beyond our threat model: there are other
ways, possibly easier, to target individuals.

If we assume the attacker is not targeting specific individuals but
rather the whole user base, the attack can still be carried out but it
wouldn’t go undetected for long.  The “reference state log” mentioned in
the blog post could help.

> Proposal for a fix:
>  13. Find a volunteer to actually implement this.
>  14. When creating branches that do not receive timely security updates,
>  such as wip-gnome, core-updates and staging, add a line
>
>  Authentication-Allow-Automatic-Follow: no (core-updates)
>
>  to the commit message.
>  15. When updating guix from a commit A to commit B, additionally verify
>  whether there exists a path from A to B that does _not_ have a 
>
>  Authentication-Allow-Automatic-Follow: no [branch]
>
>  line.  If no such path exists, bail out and tell the user something
>  like:
>
>  error: Refusing to switch to the branch 'branch'!
>
>  This usually means someone is trying to trick you into
>  not receiving timely security updates! Please report this
>  incident to #guix on freenode, or at bug-guix@gnu.org.
>
>  It is safe to simply run "guix pull" again later.
>  16. If there is a path from A to B that _does_ have a 
>
>  Authentication-Allow-Automatic-Follow: no [branch]
>
>  line, and another path that does _not_ have such a line,
>  that means the branch has been merged, which is totally fine,
>  so no error message is required in that case.

It’s an interesting idea.  It addresses the scenario you described
(redirecting users to a different branch) but it doesn’t address the
more general indefinite freeze attack.  I’m not sure it’s worth focusing
on this special case.  Something like the “reference state log” would
help address the general case.

Thoughts?

Thanks for thinking through it!

Ludo’.

bug#48239: rust-1.19.0 build fails

[Mark H Weaver]

Hi,

Bone Baboon via Bug reports for GNU Guix  writes:
> On a x86_64 computer when I run `guix build --no-substitutes --cores=1
> rust` it fails during the build phase of rust-1.19.0.

Thanks for the report.

> The build log of rust-1.19.0 is attached.

Here are the last few lines of the log:

--8<---cut here---start->8---
(76/77) BUILDING cargo v0.20.0
> /gnu/store/c7w05pkmcpsqbng62wlxsna2zaybl9v5-mrustc-0.9/bin/mrustc 
> src/tools/cargo/src/cargo/lib.rs -o output/cargo-build/libcargo-0_20_0.rlib 
> --crate-name cargo --crate-type rlib -C 
> emit-depfile=output/cargo-build/libcargo-0_20_0.rlib.d --crate-tag 0_20_0 -g 
> --cfg debug_assertions -O -L output -L 
> /gnu/store/c7w05pkmcpsqbng62wlxsna2zaybl9v5-mrustc-0.9/lib/mrust -L 
> output/cargo-build --extern 
> crates_io=output/cargo-build/libcrates_io-0_9_0.rlib --extern 
> crossbeam=output/cargo-build/libcrossbeam-0_2_10.rlib --extern 
> curl=output/cargo-build/libcurl-0_4_6.rlib --extern 
> docopt=output/cargo-build/libdocopt-0_7_0.rlib --extern 
> env_logger=output/cargo-build/libenv_logger-0_4_2.rlib --extern 
> error_chain=output/cargo-build/liberror_chain-0_10_0.rlib --extern 
> filetime=output/cargo-build/libfiletime-0_1_10.rlib --extern 
> flate2=output/cargo-build/libflate2-0_2_19.rlib --extern 
> fs2=output/cargo-build/libfs2-0_4_1.rlib --extern 
> git2=output/cargo-build/libgit2-0_6_6.rlib --extern 
> git2_curl=output/cargo-build/libgit2_curl-0_7_0.rlib --extern 
> glob=output/cargo-build/libglob-0_2_11.rlib --extern 
> jobserver=output/cargo-build/libjobserver-0_1_6.rlib --extern 
> libc=output/cargo-build/liblibc-0_2_22.rlib --extern 
> libgit2_sys=output/cargo-build/liblibgit2_sys-0_6_12.rlib --extern 
> log=output/cargo-build/liblog-0_3_7.rlib --extern 
> num_cpus=output/cargo-build/libnum_cpus-1_4_0.rlib --extern 
> rustc_serialize=output/cargo-build/librustc_serialize-0_3_24.rlib --extern 
> scoped_tls=output/cargo-build/libscoped_tls-0_1_0.rlib --extern 
> semver=output/cargo-build/libsemver-0_7_0.rlib --extern 
> serde=output/cargo-build/libserde-1_0_6.rlib --extern 
> serde_derive=output/cargo-build/libserde_derive-1_0_6-plugin --extern 
> serde_ignored=output/cargo-build/libserde_ignored-0_0_3.rlib --extern 
> serde_json=output/cargo-build/libserde_json-1_0_2.rlib --extern 
> shell_escape=output/cargo-build/libshell_escape-0_1_3.rlib --extern 
> tar=output/cargo-build/libtar-0_4_13.rlib --extern 
> tempdir=output/cargo-build/libtempdir-0_3_5.rlib --extern 
> term=output/cargo-build/libterm-0_4_5.rlib --extern 
> toml=output/cargo-build/libtoml-0_4_1.rlib --extern 
> url=output/cargo-build/liburl-1_4_0.rlib --extern 
> openssl=output/cargo-build/libopenssl-0_9_12.rlib
BUILDING cargo v0.20.0
> /gnu/store/c7w05pkmcpsqbng62wlxsna2zaybl9v5-mrustc-0.9/bin/mrustc 
> src/tools/cargo/src/bin/cargo.rs -o output/cargo-build/cargo --crate-name 
> cargo --crate-type bin -C emit-depfile=output/cargo-build/cargo.d --crate-tag 
> 0_20_0 -g --cfg debug_assertions -O -L output -L 
> /gnu/store/c7w05pkmcpsqbng62wlxsna2zaybl9v5-mrustc-0.9/lib/mrust -L 
> output/cargo-build --extern cargo=output/cargo-build/libcargo-0_20_0.rlib 
> --extern crates_io=output/cargo-build/libcrates_io-0_9_0.rlib --extern 
> crossbeam=output/cargo-build/libcrossbeam-0_2_10.rlib --extern 
> curl=output/cargo-build/libcurl-0_4_6.rlib --extern 
> docopt=output/cargo-build/libdocopt-0_7_0.rlib --extern 
> env_logger=output/cargo-build/libenv_logger-0_4_2.rlib --extern 
> error_chain=output/cargo-build/liberror_chain-0_10_0.rlib --extern 
> filetime=output/cargo-build/libfiletime-0_1_10.rlib --extern 
> flate2=output/cargo-build/libflate2-0_2_19.rlib --extern 
> fs2=output/cargo-build/libfs2-0_4_1.rlib --extern 
> git2=output/cargo-build/libgit2-0_6_6.rlib --extern 
> git2_curl=output/cargo-build/libgit2_curl-0_7_0.rlib --extern 
> glob=output/cargo-build/libglob-0_2_11.rlib --extern 
> jobserver=output/cargo-build/libjobserver-0_1_6.rlib --extern 
> libc=output/cargo-build/liblibc-0_2_22.rlib --extern 
> libgit2_sys=output/cargo-build/liblibgit2_sys-0_6_12.rlib --extern 
> log=output/cargo-build/liblog-0_3_7.rlib --extern 
> num_cpus=output/cargo-build/libnum_cpus-1_4_0.rlib --extern 
> rustc_serialize=output/cargo-build/librustc_serialize-0_3_24.rlib --extern 
> scoped_tls=output/cargo-build/libscoped_tls-0_1_0.rlib --extern 
> semver=output/cargo-build/libsemver-0_7_0.rlib --extern 
> serde=output/cargo-build/libserde-1_0_6.rlib --extern 
> serde_derive=output/cargo-build/libserde_derive-1_0_6-plugin --extern 
> serde_ignored=output/cargo-build/libserde_ignored-0_0_3.rlib --extern 
> serde_json=output/cargo-build/libserde_json-1_0_2.rlib --extern 
> shell_escape=output/cargo-build/libshell_escape-0_1_3.rlib --extern 
> tar=output/cargo-build/libtar-0_4_13.rlib --extern 
> tempdir=output/cargo-build/libtempdir-0_3_5.rlib --extern 
> term=output/cargo-build/libterm-0_4_5.rlib --extern 
> toml=output/cargo-build/libtoml-0_4_1.rlib --extern 
> 

bug#48024: glib-2.62.6 build fails i686

[Bone Baboon via Bug reports for GNU Guix]

Mark H Weaver writes:
> Did you also run "make"?

I have now.

> Hmm.  Can you please grep the build log for "TIMEOUT" and
> "increase-test-timeout", and show me the matching lines?

"increase-test-timeout":
```
starting phase `increase-test-timeout'
phase `increase-test-timeout' succeeded after 0.1 seconds
```

"TIMEOUT":
```
 53/259 glib:glib / rec-mutex   TIMEOUT 120.03 s
 83/259 glib:glib / 1bit-mutex  TIMEOUT 120.02 s 
 84/259 glib:glib+slow / 1bit-emufutex  TIMEOUT 180.05 s
```

Attached is the build log.

>>> (Incidentally, I *always* use Guix this way, using my own private branch
>>> of Guix, never using "guix pull", and never using substitutes.)
>>
>> This is interesting to me.
>
> I outlined how I use Guix in the following message:
>
>   https://lists.gnu.org/archive/html/guix-devel/2021-03/msg00625.html
>
> However, note that there are some significant caveats and "rough edges"
> to this approach.  I can't recommend it in good conscience, unless you
> truly need the extreme flexibility that it provides.
>
> To avoid the rough edges, I'd suggest using "guix pull --url" as
> outlined in the last two paragraphs of the message above.  For most
> purposes, I suspect you'd be much happier with that approach.

Thank you for sharing this.  Also thank you for the warning about 'significant 
caveats and "rough edges"'.

As a new user of Guix I think I will initially try to use the official
Guix repository.

However the message from Tobias Geerinckx-Rice in
https://issues.guix.gnu.org/48213 gives me the idea that your flexible
approach could be very useful if I find myself in a situation where I
have an issue that will not be addressed by an upstream project and
that has too much of a maintenance burden for Guix maintainers to take
on.



1kqwp7fsdphlkg75x0bhyw5m49y41d-glib-2.62.6.drv.bz2
Description: Binary data

bug#45236: Xboard doesn't work.

[Michael Rohleder]

fixed with 561db254a5fd72578ea2a0b0a3e8303f0ef20d85

-- 
vi /vmlinuz


signature.asc
Description: PGP signature

bug#48240: “guix copy” to host with daemon listening on TCP fails

[Ricardo Wurmus]

There are two hosts running Guix.  The target host runs 
“guix-daemon” with “--listen=0.0.0.0:”; it does not listen on 
a local socket file.  Trying to copy store items to the target 
host fails with this backtrace:


--8<---cut here---start->8---
[me@here:~] (1028) $ guix copy --to=there /gnu/store/…-profile
Backtrace:
 12 (primitive-load 
 "/gnu/store/9qjkzhlwj2792iczsyfx9n7c23g…")

In guix/ui.scm:
 2165:12 11 (run-guix-command _ . _)
In ice-9/boot-9.scm:
 1736:10 10 (with-exception-handler _ _ #:unwind? _ # _)
 1731:15  9 (with-exception-handler # ic…> …)

 1736:10  8 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
  636:37  7 (thunk)
  1305:8  6 (call-with-build-handler _ _)
  1305:8  5 (call-with-build-handler #  g…> …)

In guix/status.scm:
   799:4  4 (call-with-status-report _ _)
In guix/scripts/copy.scm:
   76:25  3 (_)
In guix/ssh.scm:
  485:39  2 (send-files # _ 
  #f …)

In ice-9/boot-9.scm:
 1669:16  1 (raise-exception _ #:continuable? _)
 1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
In procedure struct-vtable: Wrong type argument in position 1 
(expecting struct): #f

--8<---cut here---end--->8---

The (guix ssh) appears to assume that the remote daemon listens on 
a socket file.  Telling the daemon to also listen on a socket file 
works around this problem<.


--
Ricardo

bug#47641: Ongoing difficulities after linphoneqt -> linphone-desktop transition

[Maxim Cournoyer]

retitle 47641 linphone-qt has problems with text messaging using linphone 
accounts
thanks

Hello,

Maxim Cournoyer  writes:

> Hello,
>
> Raghav Gururajan  writes:
>
> [...]
>
>>> Hmm, it seems the problem strictly has to do with messaging?  That would
>>> explain how my testing of the application failed to reveal it as I don't
>>> currently used that feature (I use it for SIP calls only).
>>
>> Same here.
>>
>>> Is someone else equipped and able to reproduce it?  Perhaps Raghav
>>> (CC'd)?
>>
>> I'll try to fix it.

I could test sending text messages via a SIP account, and it seemed to
work fine.  I'm retitling this issue to reflect that it apparently
affects only Linphone accounts.

Thanks,

Maxim

bug#39101: asymptote build fails: Math formula deleted: Insufficient symbol fonts.

[Pierre Neidhardt]

Hi Ricardo,

Excellent investigation, and it turns out that it did the trick for
Asymptote!  Feel free to patch it.

Thank you so much!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

bug#39101: asymptote build fails: Math formula deleted: Insufficient symbol fonts.

[Ricardo Wurmus]

Hi Pierre,

Asymptote only succeeds building randomly on Berlin.  On my 
machine, it

systematically fails with

[…]

! Math formula deleted: Insufficient symbol fonts.


Lars and I just ran into this problem with python-nbconvert after 
I changed it to use texlive-union.  It built just fine on our 
respective laptops, but it would fail on ci.guix.gnu.org and 
another build farm.


Because TeX is a mystery to me I resorted to running the failing 
xelatex invocation under strace on ci.guix.gnu.org and my laptop 
to see where they diverge.  LaTeX looks for fonts by reading the 
“share/texmf-dist/fonts/tfm/” directory in the texlive-union; on 
the different machines the order of directories differed.  On my 
laptop LaTeX would find the fonts provided by texlive-cm first; on 
the build farms it would find the fonts provided by 
texlive-amsfonts first.


The immediate problem here was that texlive-amsfonts accidentally 
produced too many fonts — not just those it should but also 
conversions of files from its own inputs, including those provided 
by texlive-cm.  So I added texlive-amsfonts/patched in commit 
9db67988242ad514fa900e840b1494bda6001d6b (we can’t change 
texlive-amsfonts on the “master” branch) and rebuilt 
python-nbconvert with that new texlive-union.  Now that there are 
no duplicate fonts, LaTeX won’t find the wrong font first and the 
build succeeded.


I’m suspecting that its the same problem with asymptote.

Could you please try this patch and report back?  It builds fine 
for me.


diff --git a/gnu/packages/plotutils.scm b/gnu/packages/plotutils.scm
index 7f59bae770..4b89ddafd1 100644
--- a/gnu/packages/plotutils.scm
+++ b/gnu/packages/plotutils.scm
@@ -224,7 +224,7 @@ colors, styles, options and details.")
("perl" ,perl)
("texinfo" ,texinfo) ;For generating documentation
;; For the manual and the tests.
-   ("texlive" ,(texlive-union (list texlive-amsfonts
+   ("texlive" ,(texlive-union (list texlive-amsfonts/patched
 texlive-epsf
 texlive-etoolbox
 texlive-latex-base


Thanks!

--
Ricardo

bug#48238: Julia keeps build directory in the output

[zimoun]

Hi,

Packaging Julia stuff, I note something as a bug, I guess.  Julia seems
to keep references to the build directory in the output.

--8<---cut here---start->8---
$ find $(guix build julia --no-grafts) -type f \
   -exec grep '/tmp/guix-build-julia-1.5.3.drv-0' {} \;
Binary file 
/gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/lib/libjulia.so.1.5 
matches
Binary file 
/gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/lib/julia/sys.so matches
Binary file 
/gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/lib/julia/libccalltest.so.debug
 matches
Binary file 
/gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/lib/julia/libllvmcalltest.so
 matches
Binary file 
/gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/bin/.julia-real matches
Binary file 
/gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/share/julia/base.cache 
matches
Binary file 
/gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/share/julia/test/depot/compiled/v1.5/Bar/HXSAn_w3IH9.ji
 matches
Binary file 
/gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/share/julia/test/depot/compiled/v1.5/Foo/MYb1d_w3IH9.ji
 matches
Binary file 
/gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/share/julia/test/depot/compiled/v1.5/Foo/TeeT6_w3IH9.ji
 matches
Binary file 
/gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/share/julia/test/depot/compiled/v1.5/Qux/YFfiR_w3IH9.ji
 matches
Binary file 
/gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/share/julia/test/depot/compiled/v1.5/Baz/rONVA_w3IH9.ji
 matches
--8<---cut here---end--->8---

The consequence is ’dlopen’ is broken and some Julia packages cannot be
pre-compiled.  Here, an example using the Julia package manager:

--8<---cut here---start->8---
$ rm -fr ~/.julia # for the sake of the illustration ;-)
$ cat /tmp/foo.jl
using Pkg
Pkg.add("GZip")
println("# => Now let pre-compile")
using GZip
exit()

$ guix environment --ad-hoc julia -- julia --load /tmp/foo.jl
 Installing known registries into `~/.julia`
# 100.0%
  Added registry `General` to `~/.julia/registries/General`
  Resolving package versions...
  Installed GZip ─ v0.5.1
Updating `~/.julia/environments/v1.5/Project.toml`
  [92fee26a] + GZip v0.5.1
Updating `~/.julia/environments/v1.5/Manifest.toml`
  [92fee26a] + GZip v0.5.1
  [8f399da3] + Libdl
# => Now let pre-compile
ERROR: LoadError: LoadError: could not load library "libz"
libz.so: cannot open shared object file: No such file or directory
Stacktrace:

[...]

in expression starting at 
/home/simon/.julia/packages/GZip/JNmGn/src/zlib_h.jl:13
in expression starting at /home/simon/.julia/packages/GZip/JNmGn/src/GZip.jl:73
ERROR: LoadError: Failed to precompile GZip 
[92fee26a-97fe-5a0c-ad85-20a5f3185b63] to 
/home/simon/.julia/compiled/v1.5/GZip/s2LKY_jQTtL.ji.
…
--8<---cut here---end--->8---

Let tweak the GZip ’ccall’ and pre-compile again to show that the
build-directory is contained in the output, and the Julia internal trace
raises it.

--8<---cut here---start->8---
$ diff ~/.julia/packages/GZip/JNmGn/src/GZip.jl{,.orig} 
75c75
< const GZLIB_VERSION = unsafe_string(ccall(:zlibVersion, Ptr{UInt8}, ()))
---
> const GZLIB_VERSION = unsafe_string(ccall((:zlibVersion, GZip._zlib), 
> Ptr{UInt8}, ()))

$ diff ~/.julia/packages/GZip/JNmGn/src/zlib_h.jl{,.orig} 
13c13
< zlib_version =  unsafe_string(ccall(:zlibVersion, Ptr{UInt8}, ()))
---
> zlib_version =  unsafe_string(ccall((:zlibVersion, _zlib), Ptr{UInt8}, ()))
84c84
< const zlib_compile_flags = ccall(:zlibCompileFlags, UInt, ())
---
> const zlib_compile_flags = ccall((:zlibCompileFlags, _zlib), UInt, ())

$ guix environment --ad-hoc julia -- julia -e 'using GZip'
ERROR: LoadError: could not load library "libz"
libz.so: cannot open shared object file: No such file or directory
Stacktrace:
 [1] dlopen(::String, ::UInt32; throw_error::Bool) at 
/tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/usr/share/julia/stdlib/v1.5/Libdl/src/Libdl.jl:109
 [2] dlopen at 
/tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/usr/share/julia/stdlib/v1.5/Libdl/src/Libdl.jl:109
 [inlined] (repeats 2 times)

[...]

in expression starting at /home/simon/.julia/packages/GZip/JNmGn/src/GZip.jl:206
…
--8<---cut here---end--->8---


I have tried to tweak LD_LIBRARY_PATH in the julia definition and
rebuild it.  Still the same error.  Note building the julia package
takes ~2h on my machine, so the trial-error takes ages. ;-)

Another illustration:

--8<---cut here---start->8---
$ cat /tmp/bar/pkg.scm
(define-module (pkg)
  #:use-module (guix packages)
  #:use-module (guix git-download)
  #:use-module (guix build-system julia)
  #:use-module ((guix licenses) #:prefix license:))

bug#39970: guix commands broken on Azerbaijani 'az_AZ' and Turkish 'tr_TR' locales

[pelzflorian (Florian Pelz)]

On Wed, May 05, 2021 at 12:47:02AM -0400, Maxim Cournoyer wrote:
> Closing.
> 
> Thank you,
> 
> Maxim

Sorry for forgetting about this bug.  The above

LC_ALL=tr_TR.utf8 make check TESTS=tests/cran.scm

is *not* fixed, but I won’t take the time to really understand and fix
the few remaining troubles, I think.  Possibly libc bug
 is the real
issue.

Regards,
Florian

bug#48156: basic system test broken: qemu-system-x86_64: error while loading shared libraries: libXcursor.so.1: cannot open shared object file: No such file or directory

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Christopher Baines  skribis:
>
>> This is on commit 1b792e8b5275dc010c53d91062082340431204f2.
>>
>> → make check-system TESTS=basic
>> Compiling Scheme modules...
>> Selected 1 system tests...
>> The following derivation will be built:
>>/gnu/store/7dyw16iakczr7qg89rb3rgbh443cvwpc-basic.drv
>> building /gnu/store/7dyw16iakczr7qg89rb3rgbh443cvwpc-basic.drv...
>> /gnu/store/13v06bndh09k1db50yndqi7610a9170k-qemu-5.2.0/bin/qemu-system-x86_64:
>>  error while loading shared libraries: libXcursor.so.1: cannot open shared 
>> object file: No such file or directory
>
> That looks fishy.  I cannot reproduce it like this:
>
> --8<---cut here---start->8---
> $ TESTS=basic guix time-machine 
> --commit=1b792e8b5275dc010c53d91062082340431204f2 -- build -m 
> etc/system-tests.scm
>
> [...]
>
> ;;; (services (file-system-/dev/shm file-system-/sys/firmware/efi/efivars 
> urandom-seed term-tty3 term-tty2 virtual-terminal mcron term-tty4 
> console-font-tty5 console-font-tty1 user-file-systems user-processes 
> root-file-system console-font-tty2 marionette loopback syslogd nscd term-tty5 
> root file-system-/dev/pts term-tty6 file-system-/sys/kernel/debug 
> console-font-tty3 guix-daemon term-tty1 user-homes console-font-tty6 sysctl 
> console-font-tty4 term-auto host-name file-systems udev))
> # of expected passes  27
> # of skipped tests1
> successfully built /gnu/store/q1p7gbpxv37ycisdpl11vi4x86l73lmg-basic.drv
> /gnu/store/2v80zymwawb9cvf9bhdfj87f60nrcpn3-basic
> --8<---cut here---end--->8---
>
> It’s not the same derivation though.
>
> I can’t seem to find
> /gnu/store/7dyw16iakczr7qg89rb3rgbh443cvwpc-basic.drv nor
> /gnu/store/13v06bndh09k1db50yndqi7610a9170k-qemu-5.2.0.  Where do they
> come from?

I've done a bit more digging, the qemu output is grafted, and I'm
probably getting a different grafted result since the libxcursor output
I have in my store is broken:

/gnu/store/mwcfhmiivhp4q7wax3ja8s17pk20i6w9-libxcursor-1.2.0/
└── share
└── doc
└── libxcursor-1.2.0
└── COPYING

This comes from guix.cbaines.net, so it's probably not affecting anyone
else. I checked where the build happened, and it took place on a machine
which I was playing around with overclocking, and wasn't running in a
stable way.

I'm sort of impressed things managed to break in such a specific way
though. Because of how the Guix Build Coordinator works, this build must
have taken place, something went wrong in the middle, and then the
outputs got uploaded and the build result reported all without
issue. The build log has some interesting "succeeded after 0.0 seconds"
bits at the end:

  https://guix.cbaines.net/build/d4850c59-a007-4754-b16d-d867d63bc95e/log

I'll close the bug since this seems to be a "me" problem.


signature.asc
Description: PGP signature

bug#48024: glib-2.62.6 build fails i686

[Efraim Flashner]

On Tue, May 04, 2021 at 04:01:54PM -0400, Mark H Weaver wrote:
> Hi Efraim,
> 
> Efraim Flashner  writes:
> > In glib-2.68 test_timeout and test_timeout_slow are set to 60 and 180
> > respectively.
> 
> Right.  Unfortunately, these timeouts are too short for many slower
> machines, such as 32-bit ARM systems.  Bone Baboon has also recently
> reported being unable to build 'glib' on a 32-bit i686 system due to
> these timeouts, even when making extreme efforts to reduce load from
> other processes.
> 
> > As I understand it, the tests which are are tagged '+slow' get the
> > test_timeout_slow property, with the test taking the longest on that
> > machine was glib:glib+slow / gvariant, at 65 seconds. By comparison, on
> > my Ryzen 3900XT machine it took 2.58 seconds. I figured even at double
> > that time it still fell within the 180 seconds given by default in the
> > test suite so it was likely safe to remove the substitution entirely.
> 
> I think that this recently-reported bug ()
> demonstrates that we can't safely remove the substitution.
> 
> I think that we should re-introduce the 'increase-test-timeout' phase
> for all systems on the 'core-updates' branch.  Is there a disadvantage,
> besides having to wait a couple more minutes if a test fails to
> terminate?
> 
> What do you think?
> 
>   Regards,
> Mark

I looked closer at the bug report and I see they are timing out at 60
and 180 for Bone Baboon as they currently are.

Bone Baboon: Can you build the attached test-glib.scm file and send back
the build log? I want to make sure I change the timeout to something
long enough.

You can build it with 'guix build -f test-glib.scm'

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
; vim: set filetype=guix :

(use-modules
  (gnu packages glib)
  (guix utils)
  (guix packages))

(package
  (inherit glib)
  (replacement #f)
  (arguments
   (substitute-keyword-arguments (package-arguments glib)
 ((#:phases phases)
  `(modify-phases ,phases
 (add-after 'unpack 'adjust-test-timeout
   (lambda _
 (substitute* "meson.build"
   (("test_timeout = 60")
"test_timeout = 600")
   (("test_timeout_slow = 120")
"test_timeout_slow = 1200"))
 #t)))


signature.asc
Description: PGP signature

bug#41413: guix-install.sh broken on Gentoo

[Vincent Legoll]

Hello,

On Wed, May 5, 2021 at 6:56 AM Maxim Cournoyer
 wrote:
> It seems the installer is working fine as per your tests and that the
> original issue cannot be reproduced.  I'm closing this bug.

Yes, I stopped working on that (guix-install.sh), not enough
feedback / reviews / merges, so it stalled.

Thanks anyways

-- 
Vincent Legoll

bug#39970: guix commands broken on Azerbaijani 'az_AZ' and Turkish 'tr_TR' locales

[Taylan Kammer]

On 12.03.2020 12:02, pelzflorian (Florian Pelz) wrote:
> 
> Guile’s behavior that i is not among [a-z] has been confirmed as
> unexpected by a natively Turkish friend of mine.  It is different from
> the behavior of current glibc:
> 
> florian@florianmacbook ~$ cat iyiyim.c
> #include 
> #include 
> #include 
> #define STR "iyiyım"
> int main (intargc,
>   char** argv)
> {
>   regex_t only_letters;
>   int r = regcomp (_letters, "[a-z]+", REG_EXTENDED);
>   if (r != 0)
> printf ("This error does not happen.\n");
>   r = regexec (_letters, STR, 1, malloc (sizeof (regmatch_t)), 0);
>   if (r == 0)
> printf ("The string " STR " matched!\n");
>   else
> printf ("No match for " STR ".\n");
> }
> florian@florianmacbook ~$ gcc -o iyiyim iyiyim.c
> florian@florianmacbook ~$ LANG=tr_TR.utf8 ./iyiyim 
> The string iyiyım matched!
> 
> Apparently Guile uses a bundled regular expression library rather than
> glibc.  I can try making Guile use a newer GNUlib for its regular
> expressions, maybe that helps.  Shall I file a separate bug for Guile?
> 
Also native Turkish speaker here, and yeah that seems like a clear bug.

By the way, Turkish doesn't have q, w, or x.  So if [a-z] is interpreted
by locale, it would fail to match those letters.  I suppose that doesn't
matter for the patch you guys used but it might have been part of the
original problem.

The dotless lowercase i / dotted uppercase I mostly bites programmers in
case conversion.  The uppercase of i is İ and the lowercase of I is ı.
There was even an exploit in GitHub related to this:

  https://eng.getwisdom.io/hacking-github-with-unicode-dotless-i/


- Taylan