[core-updates] u-boot source cannot be downloaded

  • Done
  • quality assurance status badge
Details
5 participants
  • Bengt Richter
  • Danny Milosavljevic
  • Leo Famulari
  • Ludovic Courtès
  • Maxim Cournoyer
Owner
unassigned
Submitted by
Danny Milosavljevic
Severity
normal

Debbugs page

Danny Milosavljevic wrote 4 years ago
(address . bug-guix@gnu.org)
20210213033752.499715c0@scratchpost.org
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?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAmAnO4AACgkQ5xo1VCww
uqX3VAf/YbMPL0o4fkApadPDPszNoOKYkXkGNL6IW9Ti1T49bYD4GvAZbTkS1KiE
wytukyZJ0Ptt+3RedsxfNy6ibGiXLcrWwMgAwIXc+EsYbXWh6W9rof0uCpXV6tNN
epBvvl2bMT/fDh4+h4EjMnSYWA2Ld4U8Q15eE/e2b1t/lFNpAm1Q1tldgZEviq14
cWsyO5eUnb7B/DDFZ2bafr5QGpzEnjydlIi5AaGbRqpn04hV1zdpeqZT7tjwwWwx
mXYooWywqa/G/5dv7KPasKnED+8EawcmdUv71l4qahBdZ1BcJUErYG1nudme83T9
xqFN5oFt5XDT37xygYGX1Y32RTBS5g==
=oQuq
-----END PGP SIGNATURE-----


Leo Famulari wrote 4 years ago
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 46482@debbugs.gnu.org)
YCdFTBtwUDdkPlfl@jasmine.lan
On Sat, Feb 13, 2021 at 03:37:52AM +0100, Danny Milosavljevic wrote:
Toggle quote (4 lines)
> Changing the URL to "https" instead of "ftp" would work.
> Changing it to "http" instead of "ftp" would also work.
> Which should we use?

I recommend HTTPS over HTTP. Although we don't verify the HTTPS
certificate with the X.509 PKI for this case [0], it still protects
against passive eavesdropping.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAmAnRUwACgkQJkb6MLrK
fwhQpRAA2tPFiBJJOfmad/RkPMm0QsQxTa04acMcxAkohOG6n54SbxkP6QCYXH0k
1fZL5UxyTJWHU2DPoM0AVS7NNGObTFx8GYEBg0hVYzZiWRg6arninlf3VVjyqLPg
P7IsT7dvGamr6B1P9lfs4yrTGJUOvISP4yPBW+U245eH3eC01yqmFLXLTvL8CSC+
6ZW11XtGwHVKG1lUKtNCQRrquY0xpoWR4L7bmq1fXRe7aWR+l7p7fzOPYA95CVcX
ZdJCZkU/fOZrS6H2srEBqVFGetcJc+0mFOXQ1KyAqnrgFcsKc5ZUQ7jLtgk9PeeL
zpW4Jx0uMZ55kNCWRO67hCH6Nl4hg7lRNJ47TAZ4h7tqH3GYuCYhyTxiicRvwhn4
Dee4KP95uNpUA7dZ6j11dGktvARkQyjAPa4ppgJXJIg22Lvv6LWZNSK8FCJH1n2Y
O4Y6EHcB3BjEkVvwoMgfA7UfXxnmDWKfjp8Rd8I4Iy0s8T3SsoTKem+FHZYZTQ6Y
sZhc36vk6Ap4mxFchmfCukJ2VOV15MScrSuuLQTzwZJIE0hXHvqDLJ1Ub/4dS3Cv
qzbdOfyLpfhYDB/Epmzl7WKSeh0sV8Cj/W3H2MQXiT9vXNTeeDKqP7Srz2Jhe+qp
m1IXXisQDvXOQ3j6upD3InexxkKpV2GYyPR4Gl94A3fDHrj5y9I=
=+pvC
-----END PGP SIGNATURE-----


Bengt Richter wrote 4 years ago
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 46482@debbugs.gnu.org)
20210213183409.GA4220@LionPure
Hi,

On +2021-02-13 03:37:52 +0100, Danny Milosavljevic wrote:
Toggle quote (15 lines)
> 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):
Toggle snippet (3 lines)
4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30)

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
Leo Famulari wrote 4 years ago
(name . Bengt Richter)(address . bokr@bokr.com)
YCgkjWU++McEBcsK@jasmine.lan
On Sat, Feb 13, 2021 at 07:34:09PM +0100, Bengt Richter wrote:
Toggle quote (4 lines)
> 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:

Bengt Richter wrote 4 years ago
(name . Leo Famulari)(address . leo@famulari.name)
20210214035750.GA4673@LionPure
Hi Leo et al,

On +2021-02-13 14:12:13 -0500, Leo Famulari wrote:
Toggle quote (19 lines)
> 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
Ludovic Courtès wrote 4 years ago
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 46482@debbugs.gnu.org)
87r1lckrjo.fsf@gnu.org
Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Toggle quote (2 lines)
> 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"

Can we add mirror URLs to the ‘origin’, similar to what I did in
9d01749feaa1586b1caf449712116e7518bb2303?

Ludo’.
Maxim Cournoyer wrote 3 years ago
control message for bug #46482
(address . control@debbugs.gnu.org)
878rox4psl.fsf@gmail.com
close 46482
quit
?
Your comment

This issue is archived.

To comment on this conversation send an email to 46482@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 46482
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help