Re: caching apt package lists/Raspbian

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: caching apt package lists/Raspbian

TarotApprentice
It turns out it still doesn't cache them the Packages.xz. From discussions over on the RaspberryPi forums it seems its hitting the following (this is just the Packages.xz) in order to match their main, contrib, non-free and rpi repos.

$ apt-get --print-uris update

'http://archive.raspberrypi.org/debian/dists/buster/main/binary-armhf/Packages.xz' 
archive.raspberrypi.org_debian_dists_buster_main_binary-armhf_Packages 0

'http://archive.raspberrypi.org/debian/dists/buster/main/binary-all/Packages.xz'
archive.raspberrypi.org_debian_dists_buster_main_binary-all_Packages 0

'http://raspbian.raspberrypi.org/raspbian/dists/buster/main/binary-armhf/Packages.xz'
raspbian.raspberrypi.org_raspbian_dists_buster_main_binary-armhf_Packages 0

'http://raspbian.raspberrypi.org/raspbian/dists/buster/main/binary-all/Packages.xz'
raspbian.raspberrypi.org_raspbian_dists_buster_main_binary-all_Packages 0

'http://raspbian.raspberrypi.org/raspbian/dists/buster/contrib/binary-armhf/Packages.xz'
raspbian.raspberrypi.org_raspbian_dists_buster_contrib_binary-armhf_Packages 0

'http://raspbian.raspberrypi.org/raspbian/dists/buster/contrib/binary-all/Packages.xz'
raspbian.raspberrypi.org_raspbian_dists_buster_contrib_binary-all_Packages 0

'http://raspbian.raspberrypi.org/raspbian/dists/buster/non-free/binary-armhf/Packages.xz'
raspbian.raspberrypi.org_raspbian_dists_buster_non-free_binary-armhf_Packages 0

'http://raspbian.raspberrypi.org/raspbian/dists/buster/non-free/binary-all/Packages.xz'
raspbian.raspberrypi.org_raspbian_dists_buster_non-free_binary-all_Packages 0

'http://raspbian.raspberrypi.org/raspbian/dists/buster/rpi/binary-armhf/Packages.xz' 
raspbian.raspberrypi.org_raspbian_dists_buster_rpi_binary-armhf_Packages 0

'http://raspbian.raspberrypi.org/raspbian/dists/buster/rpi/binary-all/Packages.xz' 
raspbian.raspberrypi.org_raspbian_dists_buster_rpi_binary-all_Packages 0 

I thought I would paste these into redbot. A bunch of them are returning HTTP 404 - Not found responses. That first one for example gives a 404 response. Would that be enough to force squid to have to download the ones it can find each and every time? Any other suggestions on how to debug this?

MarkJ
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: caching apt package lists/Raspbian

joseph
look at
http://raspbian.raspberrypi.org/raspbian/dists/buster/contrib/

binary-all  dose not exist lol 404 response normal

squid has nothing to do with it so test your link wen you have problem
without squid
squid can not cache ghost



-----
**************************
***** Crash to the future  ****
**************************
--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
************************** ***** Crash to the future **** **************************
Reply | Threaded
Open this post in threaded view
|

Re: caching apt package lists/Raspbian

Amos Jeffries
Administrator
In reply to this post by TarotApprentice
On 19/08/19 2:06 am, TarotApprentice wrote:
> It turns out it still doesn't cache them the Packages.xz. From
> discussions over on the RaspberryPi forums it seems its hitting the
> following (this is just the Packages.xz) in order to match their
> main, contrib, non-free and rpi repos.
>
> $ apt-get --print-uris update
>
...

>
> I thought I would paste these into redbot. A bunch of them are
> returning HTTP 404 - Not found responses. That first one for example
> gives a 404 response. Would that be enough to force squid to have to
> download the ones it can find each and every time?

For those ones yes. As redbot says Squid is allowed to cache them, but
not to use the resulting HIT later. Unless something exceptional occurs
like not being able to contact the origin for an update.


> Any other suggestions on how to debug this?
>

You can try "debug_options 11,2 22,3 20,3" and see what is going on for
the ones that are not 404.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users