Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

apt-file on debian stretch still won't work with aptly repository #756

Closed
andsten opened this issue Jul 6, 2018 · 4 comments
Closed

apt-file on debian stretch still won't work with aptly repository #756

andsten opened this issue Jul 6, 2018 · 4 comments
Labels
Milestone

Comments

@andsten
Copy link

andsten commented Jul 6, 2018

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:

my published aptly mirror:

78156fa4c3dc2d9738baeeb4910d6dc4    31931 main/Contents-amd64.gz

official mirror:

 71ffc92735ac8621dc4bface380b8311 455005144 main/Contents-amd64
 000fc46f21ad2c46d1affa5f8e829527 31399649 main/Contents-amd64.gz

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 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 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).

@smira smira added this to the 1.4.0 milestone Jul 13, 2018
@smira smira added the bug label Jul 13, 2018
@smira
Copy link
Contributor

smira commented Jul 13, 2018

@andsten thanks for detailed report!

that's certainly bug in aptly, I'll try to fix it for the next release

@andsten
Copy link
Author

andsten commented Jul 16, 2018

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:

 43e132f301982fcb35344ff40f94bb71 431586105 main/Contents-amd64
 385561a6fee1ba2b2cb55948530804d5 30016187 main/Contents-amd64.gz

Thanks for the quick bugfix!

@andsten andsten closed this as completed Jul 16, 2018
@smira
Copy link
Contributor

smira commented Jul 16, 2018

Thanks for detailed bug report! 🙇

@smira
Copy link
Contributor

smira commented Jul 16, 2018

bugfix should be available in the next nightly build (in 15-30 minutes)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants