On Tue 05 Nov 2019 at 06:59:55 (+0100), john doe wrote: > On 10/29/2019 4:10 PM, to...@tuxteam.de wrote: > > On Tue, Oct 29, 2019 at 03:58:04PM +0100, john doe wrote: > >> On 10/29/2019 2:01 PM, to...@tuxteam.de wrote: > >>> On Tue, Oct 29, 2019 at 01:36:35PM +0100, john doe wrote: > >>>> On 10/29/2019 12:50 PM, Charles Curley wrote: > >>>>> On Tue, 29 Oct 2019 11:45:02 +0100 > >>>>> john doe <johndoe65...@mail.com> wrote: > >>>>> > >>>>>> /etc/apt/sources.list: > >>>>>> > >>>>>> http://HOSTNAME-APT-CACHER-NG>:3142/debian-security buster/updates > > > > [...] > > > >> Yes, the hostname is not the one I use. > > > > Phew :-) > > > >> For now, method 2 is used when '/etc/apt/sources.list' is created by the > >> Debian installer, so method 1 is not an option. > > > > Not clear why, but... let's assume that. > > > >> Everything else is working but not downloading the upgrade through > >> apg-cacher-ng. > >> > >> Is anyone using a proxy to download the upgrade(s) and what format is to > >> be used in '/etc/apt/sources.list'? > > > > I have used that in the past, but I do prefer the cache specification > > in apt config these days. > > > > What happens when you point your browser at your cache instance? > > > > What do the cache log files say? (Find them typically in > > /var/log/apt-cacher-ng/apt-cacher.err and ...log). > > > > I have filed a bugreport regarding this (1). > > In a nutshell, the secdeb remap rule is missing the "directory spec". > Adding the directory spec ('/debian-security') wright before the first > semicolon (';') fixes the issue, so the secdeb line should look like: > > Remap-secdeb: security.debian.org /debian-security ; security.debian.org > deb.debian.org/debian-security > > Thanks to anyone who has chimed in. > > > 1) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944114.
This stuff goes a bit over my head, but I wondered whether it would explain something. When I converted¹ this laptop from stretch to buster, I copied its entire stretch/apt-cacher-ng cache of .deb files into the _import directory of the new buster/apt-cacher-ng and ran the import process from its maintenance webpage. All the packages destined for the debrep side of the cache were imported into their appropriate places in the directory tree, but nothing made it into the secdeb side. Those packages were left, and remain, in the _import directory. I assume now that apt-cacher-ng could not find out the structure of the directory tree in which to place them. Could that problem arise out of your bug? (The secdeb tree is now being populated normally as a result of the usual buster security updates.) ¹ buster is a new installation; the stretch system remains behind on a twin partition; /home is a shared partition. The stretch cache was well populated with buster packages as all the other five PCs here had switched to buster already, all via this cache. Cheers, David.