Ubuntu

404 from the archive is not handled well

Reported by Won1der on 2009-10-14
56
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Aptdaemon
Medium
Unassigned
aptdaemon (Debian)
New
Unknown
aptdaemon (Ubuntu)
Medium
Unassigned
software-center (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: software-center

When trying to install Pingus from the Ubuntu Software Center It downloads to 50% and then gives the following error message:

Failed to download package files
Check your internet connection.
Details
Failed to fetch http://us.archive.ubuntu.com/ubuntu/pool/main/b/boost1.38/libboost-signals1.38.0_1.38.0-6ubuntu5_i386.deb 404 Not Found [IP: 91.189.88.31 80]

My internet is working and I have downloaded and installed other software succesfully from the software center.

ProblemType: Bug
Architecture: i386
Date: Wed Oct 14 08:20:35 2009
DistroRelease: Ubuntu 9.10
Package: software-center 0.4.6
PackageArchitecture: all
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-12.39-generic
SourcePackage: software-center
Tags: ubuntu-unr
Uname: Linux 2.6.31-12-generic i686

Won1der (won1der) wrote :

We have various options here:
- show a proper error message
- offer reload button
- reload list automatically on 404 and try again once that is finished

Changed in software-center (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
summary: - Pingus will not download past 50%
+ 404 from the archive is not handeld well
Changed in aptdaemon (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Matthew Paul Thomas (mpt) wrote :

In what sort of situation would reloading the list fix this problem?

Dan McCombs (overridex) wrote :

Hi Matthew,

The situation reloading the lists would fix this in is when a new version of the package you are trying to install has been released, so the old one has been removed from the mirrors but is still referenced in your local package list. This causes software center (or any package manager) to try to download the old, non-existent file, resulting in the 404. Reloading the package list will get the information about the new package version and try to download that instead, which solves the 404.

This is more likely to happen during a beta as well, since so many packages are being updated so often.

-Dan

Andrew (and471) on 2009-10-19
Changed in software-center (Ubuntu):
assignee: nobody → Matthew Paul Thomas (mpt)
Olivier Tilloy (osomon) on 2010-04-20
summary: - 404 from the archive is not handeld well
+ 404 from the archive is not handled well
Sebastian Heinlein (glatzor) wrote :

The error message comes from the curl library. aptdaemon only gets the error string from python-apt. we would have to parse the string and guess. so we only know that there was an error fetching a package file.

But we could enhance the error dialog to show a button to run a update-cache transaction and improve the error message.Currently it reads: Failed to download package files. Check your Internet connection.

Changed in aptdaemon:
status: New → Confirmed
importance: Undecided → Medium
Changed in aptdaemon (Debian):
status: Unknown → New
Matthew Paul Thomas (mpt) wrote :

A current example of this is bug 838217. If you try to install the package from USC, it just fails silently.

Sebastian Heinlein (glatzor) wrote :

Should we check if the cache has been updated in the last 24 hours? If this is the case we could show an alternative error message suggesting to re-updating the list. But we could also perfrom an update-cache operation automatically by aptdaemon.

Changed in aptdaemon:
status: Confirmed → In Progress
Matthew Paul Thomas (mpt) wrote :

I like Michael's third suggestion: if we get a 404, automatically reload the list and try again. If we fail a second time, then show a nice error message.

What should the message say? "Check your Internet connection" doesn't seem appropriate for a 404. Maybe "Try again in a few hours"?

Sebastian Heinlein (glatzor) wrote :

We cannot reduce this to a 404 error - since we don't know what happened. The download just fails. Kind of a black box.

The next question is if we should do this inside of the transaction or create a new update-cache transaction and requeue the current one.

Matthew Paul Thomas (mpt) wrote :

Why don't we know what happened? Does aptdaemon not have access to the HTTP status code?

Sebastian Heinlein (glatzor) wrote :

right. There are several software stacks involved: software-center -> dbus -> aptd -> python-apt -> libapt -> libcurl

We only get a possible translated error message from libcurl.

tags: added: client-server
Changed in software-center (Ubuntu):
status: Confirmed → In Progress
Changed in aptdaemon (Ubuntu):
assignee: nobody → Matthew Paul Thomas (mpt)
status: Confirmed → In Progress
Matthew Paul Thomas (mpt) wrote :

I've written up a first draft of a solution to this. <https://wiki.ubuntu.com/SoftwarePackageOperations#download-failed> In brief, when a download fails: First check whether there's an Internet connection, and complain about that if necessary. Second, try downloading the package list again, and if that fails, complain that the software channel is not available. But if it succeeds and the URL has changed, try downloading the file again, and if that fails, complain specifically that the file is missing.

Sebastian, does that make sense? The design assumes that the errors will be presented by Aptdaemon, not by USC. That cuts out two layers from the software stack, making it a little more likely that we might be able to get even smarter (e.g. distinguishing between 403 and 404 errors) in future.

Changed in aptdaemon (Ubuntu):
status: In Progress → Triaged
Changed in software-center (Ubuntu):
status: In Progress → Triaged
Changed in aptdaemon (Ubuntu):
assignee: Matthew Paul Thomas (mpt) → nobody
Changed in software-center (Ubuntu):
assignee: Matthew Paul Thomas (mpt) → nobody

Am Dienstag, den 08.05.2012, 23:42 +0000 schrieb Matthew Paul Thomas:
> I've written up a first draft of a solution to this.
> <https://wiki.ubuntu.com/SoftwarePackageOperations#download-failed> In
> brief, when a download fails: First check whether there's an Internet
> connection, and complain about that if necessary. Second, try
> downloading the package list again, and if that fails, complain that the
> software channel is not available. But if it succeeds and the URL has
> changed, try downloading the file again, and if that fails, complain
> specifically that the file is missing.
>
> Sebastian, does that make sense? The design assumes that the errors will
> be presented by Aptdaemon, not by USC. That cuts out two layers from the
> software stack, making it a little more likely that we might be able to
> get even smarter (e.g. distinguishing between 403 and 404 errors) in
> future.

I am not sure where to place all this logic. Perhaps we need some kind
of high level client / error handler in aptdaemon or move those bits
into software-center, but this would make sharing with update-manager or
any other client harder.

The tough challenge is to integrate the problem notification dialog and
the resolution confirmation dialog into one single dialog.

I will think about it and talk to mvo.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.