bug#61722: [PATCH] cpio: Properly handle Unicode characters in file names.

[Maxim Cournoyer]

Fixes .

* guix/cpio.scm (file->cpio-header): Compute the file name length in bytes 
rather than in
characters.
(file->cpio-header*, special-file->cpio-header*): Likewise.
(write-cpio-archive): Likewise, and write the file name as UTF-8 bytes, not
textually, to avoid encoding it as ISO-8859-1.

---

 guix/cpio.scm | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/guix/cpio.scm b/guix/cpio.scm
index d4a7d5f1e0..8fd7552450 100644
--- a/guix/cpio.scm
+++ b/guix/cpio.scm
@@ -170,7 +170,8 @@ (define* (file->cpio-header file #:optional (file-name file)
   #:size (stat:size st)
   #:dev (stat:dev st)
   #:rdev (stat:rdev st)
-  #:name-size (string-length file-name
+  #:name-size (bytevector-length
+   (string->utf8 file-name)
 
 (define* (file->cpio-header* file
  #:optional (file-name file)
@@ -182,7 +183,8 @@ (define* (file->cpio-header* file
 (make-cpio-header #:mode (stat:mode st)
   #:nlink (stat:nlink st)
   #:size (stat:size st)
-  #:name-size (string-length file-name
+  #:name-size (bytevector-length
+   (string->utf8 file-name)
 
 (define* (special-file->cpio-header* file
  device-type
@@ -201,7 +203,8 @@ (define* (special-file->cpio-header* file
 permission-bits)
 #:nlink 1
 #:rdev (device-number device-major device-minor)
-#:name-size (string-length file-name)))
+#:name-size (bytevector-length
+ (string->utf8 file-name
 
 (define %trailer
   "TRAILER!!!")
@@ -237,7 +240,7 @@ (define (dump-file file)
 
   ;; We're padding the header + following file name + trailing zero, and
   ;; the header is 110 byte long.
-  (write-padding (+ 110 1 (string-length file)) port)
+  (write-padding (+ 110 (bytevector-length (string->utf8 file)) 1) port)
 
   (case (mode->type (cpio-header-mode header))
 ((regular)
@@ -246,7 +249,7 @@ (define (dump-file file)
  (dump-port input port
 ((symlink)
  (let ((target (readlink file)))
-   (put-string port target)))
+   (put-bytevector port (string->utf8 target
 ((directory)
  #t)
 ((block-special)

base-commit: c756c62cfdba8d4079be1ba9e370779b850f16b6
-- 
2.39.1

bug#61742: icecat.desktop show ??????????

[Feng Shu]

/gnu/store/hhfcn8viysyz2qz9rvvqkj91i5nxzd9s-icecat-102.8.0-guix0-preview1/share/applications/icecat.desktop

[Desktop Entry]
Version=1.0
Name=GNU IceCat Web Browser
Name[ar]=?? ?? 
Name[ast]=Restolador web GNU IceCat
Name[bn]=?? ??? 
Name[ca]=Navegador web GNU IceCat
Name[cs]=GNU IceCat Webov?? prohle??
Name[da]=GNU IceCat - internetbrowser
Name[el]= GNU IceCat
Name[es]=Navegador web GNU IceCat
Name[et]=GNU IceCati veebibrauser
Name[fa]=  GNU IceCat
Name[fi]=GNU IceCat-selain
Name[fr]=Navigateur Web GNU IceCat
Name[gl]=Navegador web GNU IceCat
Name[he]=??  GNU IceCat
Name[hr]=GNU IceCat web preglednik
Name[hu]=GNU IceCat webb??ng??sz??
Name[it]=GNU IceCat Browser Web
Name[ja]=GNU IceCat 
Name[ko]=GNU IceCat ??? 
Name[ku]=Geroka tor?? GNU IceCat
Name[lt]=GNU IceCat interneto nar??ykl??
Name[nb]=GNU IceCat Nettleser
Name[nl]=GNU IceCat webbrowser
Name[nn]=GNU IceCat Nettlesar
Name[no]=GNU IceCat Nettleser
Name[pl]=Przegl??darka WWW GNU IceCat
Name[pt]=GNU IceCat Navegador Web
Name[pt_BR]=Navegador Web GNU IceCat
Name[ro]=GNU IceCat ??? Navigator Internet
Name[ru]=??-?? GNU IceCat
Name[sk]=GNU IceCat - internetov?? prehliada??
Name[sl]=GNU IceCat spletni brskalnik
Name[sv]=GNU IceCat webbl??sare
Name[tr]=GNU IceCat Web Taray??c??s??
Name[ug]=GNU IceCat 
Name[uk]=??-?? GNU IceCat
Name[vi]=Tr??nh duy???t web GNU IceCat
Name[zh_CN]=GNU IceCat ???
Name[zh_TW]=GNU IceCat ???
Comment=Browse the World Wide Web
Comment[ar]=   
Comment[ast]=Restola pela Rede
Comment[bn]=??? ?? 
Comment[ca]=Navegueu per la web
Comment[cs]=Prohlen?? str??nek World Wide Webu
Comment[da]=Surf p?? internettet
Comment[de]=Im Internet surfen
Comment[el]=   ?? 
?? (Web)
Comment[es]=Navegue por la web
Comment[et]=Lehitse veebi
Comment[fa]=??  ?? ??   

Comment[fi]=Selaa Internetin WWW-sivuja
Comment[fr]=Naviguer sur le Web
Comment[gl]=Navegar pola rede
Comment[he]=?? ?? 
Comment[hr]=Pretra??ite web
Comment[hu]=A vil??gh??l?? b??ng??sz??se
Comment[it]=Esplora il web
Comment[ja]=???
Comment[ko]=?? ?? 
Comment[ku]=Li tor?? bigere
Comment[lt]=Nar??ykite internete
Comment[nb]=Surf p?? nettet
Comment[nl]=Verken het internet
Comment[nn]=Surf p?? nettet
Comment[no]=Surf p?? nettet
Comment[pl]=Przegl??danie stron WWW
Comment[pt]=Navegue na Internet
Comment[pt_BR]=Navegue na Internet
Comment[ro]=Naviga??i pe Internet
Comment[ru]= ?? 
Comment[sk]=Prehliadanie internetu
Comment[sl]=Brskajte po spletu
Comment[sv]=Surfa p?? webben
Comment[tr]=??nternet'te Gezinin
Comment[ug]=?? ?? ?? 

Comment[uk]=  ??
Comment[vi]=? duy???t c??c trang web
Comment[zh_CN]=???
Comment[zh_TW]=??
GenericName=Web Browser
GenericName[ar]=?? ??
GenericName[ast]=Restolador Web
GenericName[bn]=??? 
GenericName[ca]=Navegador web
GenericName[cs]=Webov?? prohle??
GenericName[da]=Webbrowser
GenericName[el]= 
GenericName[es]=Navegador web
GenericName[et]=Veebibrauser
GenericName[fa]= 
GenericName[fi]=WWW-selain
GenericName[fr]=Navigateur Web
GenericName[gl]=Navegador Web
GenericName[he]=?? ??
GenericName[hr]=Web preglednik
GenericName[hu]=Webb??ng??sz??
GenericName[it]=Browser web
GenericName[ja]=
GenericName[ko]=??? 
GenericName[ku]=Geroka tor??
GenericName[lt]=Interneto nar??ykl??
GenericName[nb]=Nettleser
GenericName[nl]=Webbrowser
GenericName[nn]=Nettlesar
GenericName[no]=Nettleser
GenericName[pl]=Przegl??darka WWW
GenericName[pt]=Navegador Web
GenericName[pt_BR]=Navegador Web
GenericName[ro]=Navigator Internet
GenericName[ru]=??-??
GenericName[sk]=Internetov?? prehliada??
GenericName[sl]=Spletni brskalnik
GenericName[sv]=Webbl??sare
GenericName[tr]=Web Taray??c??
GenericName[ug]=
GenericName[uk]=??-??
GenericName[vi]=Tr??nh duy???t Web
GenericName[zh_CN]=???
GenericName[zh_TW]=???
Keywords=Internet;WWW;Browser;Web;Explorer
Keywords[ar]=;;??;??;
Keywords[ast]=Internet;WWW;Restolador;Web;Esplorador
Keywords[ca]=Internet;WWW;Navegador;Web;Explorador;Explorer
Keywords[cs]=Internet;WWW;Prohle??;Web;Explorer
Keywords[da]=Internet;Internettet;WWW;Browse

bug#61684: can't compose 'with-patch' with 'with-source'

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi Maxim,
>
> Maxim Cournoyer  skribis:
>
>> Given 'with-source' discards any patch from the original source, I thought
>> I could at least add them back via 'with-patch', but it appears this
>> does not work:
>>
>> scheme@(gnu packages jami)> (options->transformation 
>>  `((with-source . 
>> "libjami@20230220.0=/home/maxim/src/jami/jami-20230220.0.tar.gz")
>>(with-patch . ,(string-append 
>>"libjami=" (search-patch 
>>
>> "jami-disable-integration-tests.patch")
>> $6 = #
>> scheme@(gnu packages jami)> ($6 libjami)
>> $7 = #
>> scheme@(gnu packages jami)> (package-source $7)
>> $8 = #< uri: "/home/maxim/src/jami/jami-20230220.0.tar.gz" 
>> recursive?: #t>
>> scheme@(gnu packages jami)>
>>
>> The downloaded-file resulting package source has lost the patch, and no
>> error got produced, leaving the user to discover this limitation by
>> themselves.
>
> The order of options matters; in this case, you need to do it the other
> way around:
>
> scheme@(guile-user)> (options->transformation '((with-patch . 
> "jami=/tmp/t.patch")
>   (with-source . 
> "jami=http://example.org/foo.tar.gz";)))
> $18 = #
> scheme@(guile-user)> ($18 jami)
> $19 = #
> scheme@(guile-user)> (package-source $19)
> $20 = #< name: "jami-20230206.0-source" gexp: # guix/transformations.scm:688:19 7f7e6b6c8d50> guile: #f options: 
> (#:local-build? #t)>
>
> The  bit comes from the ‘with-patch’ transformation, to
> apply the patch to the .
>
> If you do it the other way around, the effect of ‘with-patch’ is
> canceled by that of ‘with-source’, which does not preserve patches.  So
> strictly speaking, both options had an effect, but they were
> contradictory.

Hm.  That seems sub-optimal; it seems to me that ideally, the
transformations would be additive, so that users would not need to care
about the ordering.  Or perhaps, alternatively, we could enforce such
ordering at the implementation level (sorting the transformations in the
order that is required).

> Note that ordering is “specified”, notably with the test added in
> 0f024554e63a49e20c2a7a67e928073c266bf5c5 (this is crucial for our HPC
> users, who routinely combine a whole bunch of options; you have no idea
> how far they go once you give them the tool :-)).  I don’t think the
> manual explicitly states it though.

It doesn't seem to be, indeed.  But I wish we wouldn't need to (see my
above suggestions/ideas).

-- 
Thanks,
Maxim

bug#61646: Bandwidth-induced offload timeout abort whole operating

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> I can reproduce this rather easily on my system:
>
> $ ./pre-inst-env guix build icedove
> The following derivations will be built:
>   /gnu/store/l6r93asndd0kwv7024iyrl71zd0lbpbq-icedove-102.7.2.drv
>   /gnu/store/8zi808086b3vlfjrhdm87fgljziwdqx2-icedove-l10n-102.7.2.drv
>   /gnu/store/v0sq7rb8fk36kjasb27a71z1a27wxb1s-icedove-minimal-102.7.2.drv
> process 19542 acquired build slot '/var/guix/offload/localhost:/0'
> normalized load on machine 'localhost' is 0.08
> building 
> /gnu/store/8zi808086b3vlfjrhdm87fgljziwdqx2-icedove-l10n-102.7.2.drv...
> process 19548 acquired build slot '/var/guix/offload/localhost:/1'
> normalized load on machine 'localhost' is 0.08
> building 
> /gnu/store/v0sq7rb8fk36kjasb27a71z1a27wxb1s-icedove-minimal-102.7.2.drv...
> guix offload: sending 1 store item (558 MiB) to 'localhost'...
> exporting path 
> `/gnu/store/bwb5hcdyzgq16kmbsva7ax0zq6lzg78z-icedove-102.7.2.tar.xz'
> guix offload: error: failed to connect to 'localhost': Timeout connecting to 
> localhost
> cannot build derivation 
> `/gnu/store/l6r93asndd0kwv7024iyrl71zd0lbpbq-icedove-102.7.2.drv': 1 
> dependencies couldn't be built
> guix build: error: build of
>   `/gnu/store/l6r93asndd0kwv7024iyrl71zd0lbpbq-icedove-102.7.2.drv' failed
>
> The third derivation tries to get a build slot and times out, because
> the first two have already saturated the bandwidth of the link and it
> takes more time than expected to get a reply.

Weird.  Since the it’s a timeout while connecting, I suppose the patch
below would improve the situation:

diff --git a/guix/scripts/offload.scm b/guix/scripts/offload.scm
index 578b3b9888..90cf97401c 100644
--- a/guix/scripts/offload.scm
+++ b/guix/scripts/offload.scm
@@ -220,7 +220,7 @@ (define* (open-ssh-session machine #:optional max-silent-time)
 (session (make-session #:user (build-machine-user machine)
#:host (build-machine-name machine)
#:port (build-machine-port machine)
-   #:timeout 10   ;initial timeout (seconds)
+   #:timeout 30   ;initial timeout (seconds)
;; #:log-verbosity 'protocol
#:identity (build-machine-private-key machine)
 

WDYT?

Ludo’.

bug#61684: can't compose 'with-patch' with 'with-source'

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> Given 'with-source' discards any patch from the original source, I thought
> I could at least add them back via 'with-patch', but it appears this
> does not work:
>
> scheme@(gnu packages jami)> (options->transformation 
>  `((with-source . 
> "libjami@20230220.0=/home/maxim/src/jami/jami-20230220.0.tar.gz")
>(with-patch . ,(string-append 
>"libjami=" (search-patch 
>
> "jami-disable-integration-tests.patch")
> $6 = #
> scheme@(gnu packages jami)> ($6 libjami)
> $7 = #
> scheme@(gnu packages jami)> (package-source $7)
> $8 = #< uri: "/home/maxim/src/jami/jami-20230220.0.tar.gz" 
> recursive?: #t>
> scheme@(gnu packages jami)>
>
> The downloaded-file resulting package source has lost the patch, and no
> error got produced, leaving the user to discover this limitation by
> themselves.

The order of options matters; in this case, you need to do it the other
way around:

--8<---cut here---start->8---
scheme@(guile-user)> (options->transformation '((with-patch . 
"jami=/tmp/t.patch")
(with-source . 
"jami=http://example.org/foo.tar.gz";)))
$18 = #
scheme@(guile-user)> ($18 jami)
$19 = #
scheme@(guile-user)> (package-source $19)
$20 = #< name: "jami-20230206.0-source" gexp: # guile: #f options: 
(#:local-build? #t)>
--8<---cut here---end--->8---

The  bit comes from the ‘with-patch’ transformation, to
apply the patch to the .

If you do it the other way around, the effect of ‘with-patch’ is
canceled by that of ‘with-source’, which does not preserve patches.  So
strictly speaking, both options had an effect, but they were
contradictory.

Note that ordering is “specified”, notably with the test added in
0f024554e63a49e20c2a7a67e928073c266bf5c5 (this is crucial for our HPC
users, who routinely combine a whole bunch of options; you have no idea
how far they go once you give them the tool :-)).  I don’t think the
manual explicitly states it though.

HTH,
Ludo’.

bug#61625: Package download speed calculation, spurious results?

[Ludovic Courtès]

Hi,

francismb  skribis:

>  graphviz-2.49.0  1.2MiB
>  1.15GiB/s 00:00 [  ]   5.1%
>  graphviz-2.49.0  1.2MiB
>   2.2MiB/s 00:01 [##] 100.0%
>
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
>
> I'm not behind a ~ >100MB connection, and it's curious to get 1.15GiB/s
> here, is that somehow the value from some cache? or is a spurious
> calculation? (IMHO nothing that releases the packaging unusable thus low
> priority, just curiosity, is that a bug?)

As you can see, the 1.15GiB/s was printed while Guix had downloaded just
5.1% of 1.2 MiB, meaning 61 KiB.

The time it takes to download 61 KiB is very small, which is why you can
end up with surprising values when dividing that by the time it took.

Notice that the final result of 2.2 MiB/s is probably accurate.

There’s not much to do here, except perhaps not displaying anything
until at a bigger chunk of time has elapsed.

Ludo’.

bug#61732: "Unbound variable: %build-inputs" in Cross-Compilation Context

[Wicki Gabriel (wicg)]

Sorry, that last email was sent a little too early.


I tried said cross-compilation with this command: `guix build perl-gd 
--target=aarch64-linux-gnu` and could provoke the same error message also with 
perl-commonmark​.

It also happens with riscv64-linux-gnu and arm-linux-gnueabihf as target (i 
haven't tested all of them, though).

bug#61732: "Unbound variable: %build-inputs

[Wicki Gabriel (wicg)]

Hello

I get the following error message when trying to cross-compile perl-gd:
```
Backtrace:
  15 (primitive-load "/gnu/store/m65ipkgj9d9l2in8yp9w82npqbb?")
In ice-9/eval.scm:
   214:21 14 (_ #f)
   217:50 13 (lp (# ?))
   217:50 12 (lp (# ?))
   217:50 11 (lp (# ?))
   217:50 10 (lp (# ?))
   217:50  9 (lp (# ?))
   217:50  8 (lp (# ?))
   217:50  7 (lp (# ?))
   217:50  6 (lp (# ?))
   217:33  5 (lp (# ?))
   191:35  4 (_ #f)
   196:43  3 (_ #f)
   196:35  2 (_ #f)
   223:20  1 (proc #)
In unknown file:
   0 (%resolve-variable (7 . %build-inputs) #)

ERROR: In procedure %resolve-variable:
Unbound variable: %build-inputs
```

Not sure where it comes from.

bug#61698: Incorrect Native *_PATH's when linux source is not a tarball.

[Mitchell Schmeisser via Bug reports for GNU Guix]

This is a bit of a convoluted bug but here it goes. The title may not be
entirely correct.

When ~set-paths~ is called it adds all of the inputs to ~C_INCLUDE_PATH~
and friends /except/ the source input.

#+BEGIN_SRC scheme
(define-public linux-zynq
  (customize-linux #:name "linux-zynq"
   #:linux linux-libre-5.15
   #:source (package-source linux-xlnx-5.15.0)
   #:defconfig "xilinx_zynq_defconfig"))
#+END_SRC

However, below is a snippet from the `set-paths` phase targeting 
arm-linux-gnueabihf
>>>

environment variable `C_INCLUDE_PATH' set to 
`/gnu/store/1y1ycvzgg363ih16qs5nhmlsmn77kjl7-git-checkout/include:/gnu/store/plr00nij45964cyy7sfcg5rcsi8hks0h-openssl-1.1.1l/include:/gnu/store/jp6027624wl2f4xx5yz1vjzd2b9yvwl9-elfutils-0.183/include:/gnu/store/b4mskl4py1zqmxdy1v260r3h6x5p92fm-flex-2.6.4/include:/gnu/store/fwbiihd2sbhai63y1pvvdh0f2bakfzrf-gmp-6.2.1/include:/gnu/store/pmq05n0q25v4qjyibxfrp53v4391k7vh-mpfr-4.1.0/include:/gnu/store/ba02g5xkqiss6s5z8mbj9cvkal6l7b9g-mpc-1.2.1/include:/gnu/store/pdf9myikb674k906x70g3yzs72f61qm3-gcc-cross-arm-linux-gnueabihf-10.3.0/include:/gnu/store/0na4hgqh61fpc73dj9qgval3wdbsr393-binutils-cross-arm-linux-gnueabihf-2.37/include:/gnu/store/s3hl12jxz9ybs7nsy7kq7ybzz7qnzmsg-bzip2-1.0.8/include:/gnu/store/c8isj4jq6knv0icfgr43di6q3nvdzkx7-xz-5.2.5/include:/gnu/store/4ic6244i3ca4b4rxc2wnrgllsidyishv-file-5.39/include:/gnu/store/690qz3fg334dpwn3pn6k59n4wc943p2b-gawk-5.1.0/include:/gnu/store/55cbpsi18mahg131nmiya6km5b4mscfa-make-4.3/include:/gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/include:/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include:/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/include:/gnu/store/6mjww4iz4xdan74d5bbjfh7il8rngfkk-linux-libre-headers-5.10.35/include'

<<<

This only happens when source is a git repository, and only when
building the kernel.
When a tarball is used this does not happen because it is not a directory in 
the store.

When other packages with git sources are cross compiled their
C_INCLUDE_PATH does not contain the sources.

During the configure phase some includes in the kconfig program end up
linking there way back to =/gnu/store/...git-checkout/include/linux/=
because it is top priority in `C_INCLUDE_PATH`.


- Mitchell

bug#61697: Chromium with guix shell container from the manual doesn't work.

[em...@msavoritias.me]

Followed the manual for guix shell here: 
https://guix.gnu.org/en/manual/devel/en/guix.html#Invoking-guix-shell


Initially I wanted to setup an icecat container so I just removed 
chromium for icecat, I got this error:


```

guix shell --container --network --no-cwd icecat --preserve='^DISPLAY$' 
-- icecat

Authorization required, but no authorization protocol specified
Unable to init server: Could not connect: Connection refused
Error: cannot open display: :0.0

```


I tried chromium too. It still errors out but with a different error:

```

guix shell --container --network --no-cwd ungoogled-chromium 
--preserve='^DISPLAY$' -- chromium

Authorization required, but no authorization protocol specified
[1:1:0221/164151.354628:ERROR:ozone_platform_x11.cc(238)] Missing X 
server or $DISPLAY
[1:1:0221/164151.354678:ERROR:env.cc(255)] The platform failed to 
initialize.  Exiting.


```


Chromium starts just fine without the container flag so the problem 
seems to be in the container flag specifically.



Msavoritias