Incomplete download due to "giving up on URL" for translations #138
Assignees
Labels
Comments
|
Note to self: Probably a bug in how we are cycling through the supported compression types.. |
|
I seem to be seeing the same problem. The get operation seems to download the .xz version of a file, then throw an error when it tries to download a non-existent .lzma version of that same file: |
|
In my tests, I see all working perfect. In the case below, where it succeeds, it reports with: OTOH, in cases where it found no file with supported formats, it finally errors out. Which is what the designed behavior is. apt-offline uses some color coding in place in terminals. But looks like the choice of colors to differentiate in between success and verbose messages is very minor. See below screenshot.
|
rickysarraf
added a commit
that referenced
this issue
Jul 9, 2021
verbose message facility was using Cyan before. That and the success message facility with color Green, looked almost similar on my Konsole terminal. Make these message colors stand out clear so that it is easy to spot the differences. This can be helpful in example bugs like: #138
|
In the initial comment, that from @jgoerzen , his example reported of Translation files failing first, and then succeeding later; which ideally should be reported a success. The problem is: In this real example snippet, on my machine, The other 2 links may/may not be available depending on the mirror admins choice. What should we do in |
|
Yes. With
I would like to close this bug report as I don't see any buggy behavior here. |
|
Or maybe we should suppress those errors entirely ? The code that handles this cycling is separated already. So it shouldn't be of concern. This will help in the other users too. |
|
Okay!! I'm liking it. Same signature file. Better output. And correct exit status. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
In attempting to run this - on sources.list that is out-of-the-box buster plus buster-backports - I am getting mostly success, but then these failures:
It goes on like that. Eventually ending with:
and it aborts with a nonzero exit code. Also I was running with --verbose in this example.
It looks to me that it is getting a translation file in the end, but somehow isn't recognizing this.
The text was updated successfully, but these errors were encountered: