bug#46489: [core-updates] libusb-for-axoloti build failure

[Danny Milosavljevic]

patching file libusb/descriptor.c
Hunk #1 FAILED at 1174.
1 out of 1 hunk FAILED -- saving rejects to file libusb/descriptor.c.rej
source is at 'libusb-1.0.24'
applying 
'/gnu/store/x88dkyj396g2qw109zncs25w91cdjd94-libusb-for-axoloti.patch'...
Backtrace:
   5 (primitive-load "/gnu/store/nfdzpdirawmps55qw9y7hgkiif7…")
In ice-9/eval.scm:
619:8  4 (_ #(#(# "lib…") #))
In ice-9/boot-9.scm:
142:2  3 (dynamic-wind # …)
In ice-9/eval.scm:
619:8  2 (_ #(#(#)))
In srfi/srfi-1.scm:
634:9  1 (for-each # ("/gnu/store/x8…"))
In guix/build/utils.scm:
721:6  0 (invoke "/gnu/store/4g7nsdz2yinc2rs9shiajbj5n281aaps-p…" …)

guix/build/utils.scm:721:6: In procedure invoke:
ERROR:
  1. &invoke-error:
  program: 
"/gnu/store/4g7nsdz2yinc2rs9shiajbj5n281aaps-patch-2.7.6/bin/patch"
  arguments: ("--force" "--no-backup-if-mismatch" "-p1" "--input" 
"/gnu/store/x88dkyj396g2qw109zncs25w91cdjd94-libusb-for-axoloti.patch")
  exit-status: 1
  term-signal: #f
  stop-signal: #f
builder for 
`/gnu/store/8xjz8jp3hsff73j3cm2s012y5rhia9fy-libusb-1.0.24.tar.xz.drv' failed 
with exit code 1
build of /gnu/store/8xjz8jp3hsff73j3cm2s012y5rhia9fy-libusb-1.0.24.tar.xz.drv 
failed
View build log at 
'/var/log/guix/drvs/8x/jz8jp3hsff73j3cm2s012y5rhia9fy-libusb-1.0.24.tar.xz.drv.bz2'.
cannot build derivation 
`/gnu/store/wx3g3c0v689pd1i8v7sdm524rxwjvi8q-axoloti-libusb-1.0.24.drv': 1 
dependencies couldn't be built


pgp14H5DYMk1O.pgp
Description: OpenPGP digital signature

bug#46489: [core-updates] libusb-for-axoloti build failure

[Ricardo Wurmus]

Hi Danny,

> patching file libusb/descriptor.c
> Hunk #1 FAILED at 1174.

I’ve brought this up with Axoloti upstream 11 days ago, but haven’t
received a response yet:

https://github.com/axoloti/axoloti/issues/464

-- 
Ricardo

bug#46482: [core-updates] u-boot source cannot be downloaded

[Bengt Richter]

Hi,

On +2021-02-13 03:37:52 +0100, Danny Milosavljevic wrote:
> failed to download 
> "/gnu/store/1idpm6f9pcm9dajm90qgk6x1r6qywfv8-u-boot-2021.01.tar.bz2" from 
> "ftp://ftp.denx.de/pub/u-boot/u-boot-2021.01.tar.bz2";
> builder for 
> `/gnu/store/5s92y4l66f8qh4p4gx79jvsjaxhl208k-u-boot-2021.01.tar.bz2.drv' 
> failed to produce output path 
> `/gnu/store/1idpm6f9pcm9dajm90qgk6x1r6qywfv8-u-boot-2021.01.tar.bz2'
> build of 
> /gnu/store/5s92y4l66f8qh4p4gx79jvsjaxhl208k-u-boot-2021.01.tar.bz2.drv failed
> View build log at 
> '/var/log/guix/drvs/5s/92y4l66f8qh4p4gx79jvsjaxhl208k-u-boot-2021.01.tar.bz2.drv.bz2'.
> cannot build derivation 
> `/gnu/store/m09apasn4glhf2lvsq8bn2ci5ncjq0fz-u-boot-tools-2021.01.drv': 1 
> dependencies couldn't be built
> building 
> /gnu/store/5s4pczxlp3v8yfavmgjf93093msfaxym-ucommon-7.0.0.tar.gz.drv...
> 
> Changing the URL to "https" instead of "ftp" would work.
> Changing it to "http" instead of "ftp" would also work.
> Which should we use?
> 
> Reason is bug #46481.
> 
> But do we maybe want to change over to http or https anyway?

So long as you can check the hash of the downloaded file,
IMO other considerations ought to dominate the choice.

I would prefer something that fits in with mes-philosopy.
ftp seems old and simple, so I would vote for push-back
to fix the ftp client involved.

FWIW:
I clicked on the
"ftp://ftp.denx.de/pub/u-boot/u-boot-2021.01.tar.bz2";
URL in your "failed to download" message above, and got an open/save-as popup 
choice widget,
and clicked save-as and successfully downloaded it, and can inspect it with
tar -tjvf u-boot-2021.01.tar.bz2|less

I am running pureos (debian variant):
--8<---cut here---start->8---
4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30)
--8<---cut here---end--->8---

and was in a tilix terminal when I clicked the URL, which started 
Mozilla Firefox 78.7.0esr
which gave me the open/save-as popup choice.

IDK what firefox does with ftp://...
but it worked. I guess I could strace it, but what does firefox or icecat do on 
your box
if directed to 
ftp://ftp.denx.de/pub/u-boot/u-boot-2021.01.tar.bz2
?
HTH
-- 
Regards,
Bengt Richter

bug#46482: [core-updates] u-boot source cannot be downloaded

[Leo Famulari]

On Sat, Feb 13, 2021 at 07:34:09PM +0100, Bengt Richter wrote:
> I would prefer something that fits in with mes-philosopy.
> ftp seems old and simple, so I would vote for push-back
> to fix the ftp client involved.

FTP is more complicated than HTTP in that it requires the use of
multiple connections. Additionally, it's often blocked on corporate
networks, whereas HTTP/S is never going to be blocked (HTTPS anyways).

Based on experience in Guix, we have never had bug reports from users
who could not access sources over HTTP/S, but there have been several
reports of problems using FTP. The HTTP/S ports 80 and 443 are basically
the only ports you can depend on being open on a network that is
connected to the internet.

The creator of curl compares them here:

https://daniel.haxx.se/docs/ftp-vs-http.html

bug#46496: newlib-nano doesn't have libc_nano.a

[Nala Ginrut]

I can't build ZephyrRTOS with arm-none-eabi-nano-toolchain,
because libc_nano.a is required by ZephyrRTOS when I enabled newlib nano
config.
Then I found there's only libc_nano.a in newlib-nano path, only libc.a.

I think libc.a is for newlib, and libc_nano.a is for newlib-nano.


Best regards.


-- 
GNU Powered it
GPL Protected it
GOD Blessed it
HFG - NalaGinrut
Fingerprint F53B 4C56 95B5 E4D5 6093 4324 8469 6772 846A 0058


signature.asc
Description: PGP signature

bug#46499: Failed to compute the derivation for Guix

[Raghav Gururajan]

Hello Guix!

Guix pull failed with following error:

guix pull: error: You found a bug: the program 
'/gnu/store/r1chv4mzyrix08ibb8n3ridadc9g2rgv-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"58853df8f695b77f41ab6e1969fda2c20fd7f816"; system: "x86_64-linux";

host version: "4e902da60c84059413b838acf1dfd39c3aa73ec6"; pull-version: 1).
Please report it by email to .

Backtrace:
  11 (primitive-load 
"/gnu/store/r1chv4mzyrix08ibb8n3ridadc9g2rgv-compute-guix-derivation")

In ice-9/eval.scm:
155:9 10 (_ _)
159:9  9 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#7faf8731bf?> ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))

In ./guix/store.scm:
  2062:24  8 (run-with-store # _ 
#:guile-for-build _ #:system _ #:target _)

   1896:8  7 (_ _)
In ./guix/gexp.scm:
   258:18  6 (_ _)
   1123:2  5 (_ _)
982:2  4 (_ _)
843:4  3 (_ _)
In ./guix/store.scm:
  1944:12  2 (_ #)
   1362:5  1 (map/accumulate-builds #7faf855425f0> _ _)

  1373:15  0 (_ # _ _)

./guix/store.scm:1373:15: ERROR:
  1. &store-protocol-error:
  message: "build of 
`/gnu/store/lbzdd5wz3isjdqbd2zjlkqlgch9h5k2r-git-minimal-2.30.1.drv' failed"

  status: 100

Regards,
RG.



OpenPGP_signature
Description: OpenPGP digital signature

bug#46499: Failed to compute the derivation for Guix

[Leo Famulari]

On Sat, Feb 13, 2021 at 06:22:59PM -0500, Raghav Gururajan wrote:
> guix pull: error: You found a bug: the program
> '/gnu/store/r1chv4mzyrix08ibb8n3ridadc9g2rgv-compute-guix-derivation'
> failed to compute the derivation for Guix (version:
> "58853df8f695b77f41ab6e1969fda2c20fd7f816"; system: "x86_64-linux";
> host version: "4e902da60c84059413b838acf1dfd39c3aa73ec6"; pull-version: 1).
> Please report it by email to .

Thanks for the report...

> 
> Backtrace:
>   11 (primitive-load
> "/gnu/store/r1chv4mzyrix08ibb8n3ridadc9g2rgv-compute-guix-derivation")
> In ice-9/eval.scm:
> 155:9 10 (_ _)
> 159:9  9 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(# 7faf8731bf?> ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
> In ./guix/store.scm:
>   2062:24  8 (run-with-store # _
> #:guile-for-build _ #:system _ #:target _)
>1896:8  7 (_ _)
> In ./guix/gexp.scm:
>258:18  6 (_ _)
>1123:2  5 (_ _)
> 982:2  4 (_ _)
> 843:4  3 (_ _)
> In ./guix/store.scm:
>   1944:12  2 (_ #)
>1362:5  1 (map/accumulate-builds #
> _ _)
>   1373:15  0 (_ # _ _)
> 
> ./guix/store.scm:1373:15: ERROR:
>   1. &store-protocol-error:
>   message: "build of
> `/gnu/store/lbzdd5wz3isjdqbd2zjlkqlgch9h5k2r-git-minimal-2.30.1.drv' failed"
>   status: 100

Weird! This derivation did build on ci.guix.gnu.org.

Can you try building it "by hand" and reporting back?

Like this:

$ guix build /gnu/store/lbzdd5wz3isjdqbd2zjlkqlgch9h5k2r-git-minimal-2.30.1.drv 
--keep-failed

bug#46482: [core-updates] u-boot source cannot be downloaded

[Bengt Richter]

Hi Leo et al,

On +2021-02-13 14:12:13 -0500, Leo Famulari wrote:
> On Sat, Feb 13, 2021 at 07:34:09PM +0100, Bengt Richter wrote:
> > I would prefer something that fits in with mes-philosopy.
> > ftp seems old and simple, so I would vote for push-back
> > to fix the ftp client involved.
> 
> FTP is more complicated than HTTP in that it requires the use of
> multiple connections. Additionally, it's often blocked on corporate
> networks, whereas HTTP/S is never going to be blocked (HTTPS anyways).
> 
> Based on experience in Guix, we have never had bug reports from users
> who could not access sources over HTTP/S, but there have been several
> reports of problems using FTP. The HTTP/S ports 80 and 443 are basically
> the only ports you can depend on being open on a network that is
> connected to the internet.
> 
> The creator of curl compares them here:
> 
> https://daniel.haxx.se/docs/ftp-vs-http.html

Thanks, that was interesting.

He says (re download speed)
"Ultimately the net outcome of course differs depending on
 specific details, but I would say that for single-shot static files,
 you won't be able to measure a difference."

So in that case, what's minimal, and how vulnerable is it?

Is there a minimal quic without google upstream?

or X.25 -- dating myself ;-P

and what about TFTP/PXE ??

What would the mes-people suggest
for minimalist functionality, and minimal trust scope,
and maximal monopoly-independence, I wonder?

[meta-question] How does one gracefully go off-topic onto a tangential
discussion? I thought my original comment re expired gpg key might
have helped in some way, but my comment wanting to get the ftp fixed
intead of (or in addition to) being bypassed provoked the explanation
of how I was deluded (ok, no worries :), but I might want to
say something about separate connections isolating meta-data and data
as being a "feature" that I expect to see more of, but that would be
another step along the tangent ... or osculating circle? NNTR :-D 

-- 
Regards,
Bengt Richter

bug#46481: "guix download" with ftp URL doesn't work on IPv6 network

[宋文武]

Danny Milosavljevic  writes:

> I strongly suspect there to be some problem with the ftp client since
> that's the second file that doesn't work using guix download but does work
> using wget, on the same computer.
>
> $ guix download ftp://ftp.denx.de/pub/u-boot/u-boot-2021.01.tar.bz2
>
> Starting download of /tmp/guix-file.tORPhj
> From ftp://ftp.denx.de/pub/u-boot/u-boot-2021.01.tar.bz2...
> Throw to key `ftp-error' with args `(# "PASV" 425 
> "You cannot use PASV on IPv6 connections. Use EPSV instead.\r")'.
> failed to download "/tmp/guix-file.tORPhj" from 
> "ftp://ftp.denx.de/pub/u-boot/u-boot-2021.01.tar.bz2";
> guix download: error: ftp://ftp.denx.de/pub/u-boot/u-boot-2021.01.tar.bz2: 
> download failed

Yes, with this patch I can get it work:
>From 568ea9cc0e07eab24c7d24e228d7d391f191feca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Sun, 14 Feb 2021 12:02:57 +0800
Subject: [PATCH] ftp-client: Before 'PASV', try 'EPSV' first for IPv6.

This fixes .

* guix/ftp-client.scm (ftp-epsv, ftp-passive): New procedure.
(ftp-list, ftp-retr): Replace call to 'ftp-pasv' with 'ftp-passive'.
---
 guix/ftp-client.scm | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/guix/ftp-client.scm b/guix/ftp-client.scm
index 8d5adcb8ed..a72057d3f5 100644
--- a/guix/ftp-client.scm
+++ b/guix/ftp-client.scm
@@ -216,6 +216,19 @@ TIMEOUT, an ETIMEDOUT error is raised."
   (else
(throw 'ftp-error conn "PASV" 227 message)
 
+(define (ftp-epsv conn)
+  (let* ((message (%ftp-command "EPSV" 229 (ftp-connection-socket conn
+(string->number
+ (match:substring
+  (string-match "\\(...([0-9]+).\\)" message) 1
+
+(define (ftp-passive conn)
+  "Enter passive mode using EPSV or PASV, return a data connection port on
+success."
+  ;; IPv6 only works with EPSV, so try it first.
+  (or (false-if-exception (ftp-epsv conn))
+  (ftp-pasv conn)))
+
 (define (address-with-port sa port)
   "Return a socket-address object based on SA, but with PORT."
   (let ((fam  (sockaddr:fam sa))
@@ -232,7 +245,7 @@ TIMEOUT, an ETIMEDOUT error is raised."
   (if directory
   (ftp-chdir conn directory))
 
-  (let* ((port (ftp-pasv conn))
+  (let* ((port (ftp-passive conn))
  (ai   (ftp-connection-addrinfo conn))
  (s(socket (addrinfo:fam ai) (addrinfo:socktype ai)
(addrinfo:protocol ai
@@ -281,7 +294,7 @@ must be closed before CONN can be used for other purposes."
   ;; Ask for "binary mode".
   (%ftp-command "TYPE I" 200 (ftp-connection-socket conn))
 
-  (let* ((port (ftp-pasv conn))
+  (let* ((port (ftp-passive conn))
  (ai   (ftp-connection-addrinfo conn))
  (s(with-fluids ((%default-port-encoding #f))
  (socket (addrinfo:fam ai) (addrinfo:socktype ai)
-- 
2.30.0


Okay to push?