You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On debian stretch I observe that apt-file udpate (which on stretch
just calls apt update) does not download the Contents-<arch> index files at all
in case of using an aptly-created mirror. When using an official debian
mirror, it immediately works just fine.
Detailed Description
(I reviewed the already fixed bug report #667 and that seems not to be the same issue as described here.)
I was able to confirm that those Contents files indeed exist in my published
snapshot of a debian mirror and are also listed in the Release / InRelease files
with correct hashes. However when I compared the InRelease file of an official
debian mirror with the one of my aptly mirror, I recognized this difference:
So the official mirror also lists the hash of the uncompressed Contents file,
but the aptly mirror does not. On both the official mirror and my aptly mirror,
the actual uncompressed file Contents-amd64 does not exist, just the compressed Contents-amd64.gz exists (as it should be, to my understanding).
For other index files like Packages, the file InRelease of my aptly mirror
contains both hashes for compressed and uncompressed file, just for Contents
files it is different. Why? Might this be the problem? Or did I misinterpret
stuff?
"The checksum and sizes shall match the actual existing files. If indexes are
compressed, checksum data must be provided for uncompressed files as well, even
if not present on the server."
On debian jessie I do not get problems like that. There apt-file update was
implemented differently (not using apt update in behind... one can easily
see this because on jessie it shows progress output of curl, and on stretch
the output looks completely different).
Your Environment
I am using aptly 1.3.0 (and also tried the latest nightly build 1.3.0+17+g9a704de with the same result).
The text was updated successfully, but these errors were encountered:
I just published a snapshot with aptly (commit 747b975) to try things out and I was able to confirm that apt-file now works fine for me on debian stretch.
Files InRelease / Release now list both compressed an uncompressed Contents-* files:
On debian stretch I observe that
apt-file udpate
(which on stretchjust calls
apt update
) does not download theContents-<arch>
index files at allin case of using an aptly-created mirror. When using an official debian
mirror, it immediately works just fine.
Detailed Description
(I reviewed the already fixed bug report #667 and that seems not to be the same issue as described here.)
I was able to confirm that those
Contents
files indeed exist in my publishedsnapshot of a debian mirror and are also listed in the
Release
/InRelease
fileswith correct hashes. However when I compared the
InRelease
file of an officialdebian mirror with the one of my aptly mirror, I recognized this difference:
my published aptly mirror:
official mirror:
So the official mirror also lists the hash of the uncompressed
Contents
file,but the aptly mirror does not. On both the official mirror and my aptly mirror,
the actual uncompressed file
Contents-amd64
does not exist, just the compressedContents-amd64.gz
exists (as it should be, to my understanding).For other index files like
Packages
, the fileInRelease
of my aptly mirrorcontains both hashes for compressed and uncompressed file, just for
Contents
files it is different. Why? Might this be the problem? Or did I misinterpret
stuff?
The debian wiki says about that:
"The checksum and sizes shall match the actual existing files. If indexes are
compressed, checksum data must be provided for uncompressed files as well, even
if not present on the server."
On debian jessie I do not get problems like that. There
apt-file update
wasimplemented differently (not using
apt update
in behind... one can easilysee this because on jessie it shows progress output of
curl
, and on stretchthe output looks completely different).
Your Environment
I am using
aptly 1.3.0
(and also tried the latest nightly build1.3.0+17+g9a704de
with the same result).The text was updated successfully, but these errors were encountered: