Issue #5614: Unable to sync Wheezy Archive - Debian Support - Pulp

Actions

Send by e-mail Copy link

Issue #5614

closed

Unable to sync Wheezy Archive

Added by tomabe over 4 years ago. Updated over 3 years ago.

Status:

CLOSED - WONTFIX

Priority:

Normal

Assignee:

Sprint/Milestone:

Start date:

Due date:

Estimated time:

Severity:

2. Medium

Version - Debian:

Platform Release:

Target Release - Debian:

OS:

Triaged:

Groomed:

Sprint Candidate:

Tags:

Pulp 2

Sprint:

Quarter:

Description

Hello!
Truly sorry if this is not the place for this bug report.

Unfortunately the company I work for have some old servers left and I need to synchronize the Debian wheezy repository. When trying to sync wheezy repo in katello I get the following error:

@IOError: [Errno 2] No such file or directory: u'/var/cache/pulp/reserved_resource_worker-1@c332pc-katello/ca55db26-f364-40bc-bbac-b450445c56c0/dists/wheezy/contrib/binary-amd64/Packages.bz2@

The reason for this error seems to be that the wheezy archive repository doesn't use .bz2 extention, but instead .bz for Packages archive. Pulp looks for Packages.bz2 and not Packages.bz.

I have attached the journalctl log when this happens.

Files

journalctl-output.txt (7.44 KB) journalctl-output.txt

tomabe, 10/24/2019 10:47 AM

Actions

Copy link

Updated by mdellweg over 4 years ago

This is the right place.
However i am very sorry, the problem as you describe it is known, but will probably be a nofix. The current mechanism to select the 'best' compression algorithm [0] does not allow for a fallback on 404. Otoh changing the priority might as well break other setups.

Possible solution:
If you mirror those repositories on a local storage, it might be possible to recompress the Packages files yourself, and with the right parameters, they should end up being bit for bit compatible.

[0] https://github.com/sassoftware/python-debpkgr/blob/220d57b461c2f323a30fb44b2d1126ca4a0f9ea6/debpkgr/aptrepo.py#L267

Actions

Copy link

Updated by tomabe over 4 years ago

mdellweg wrote:

This is the right place.
However i am very sorry, the problem as you describe it is known, but will probably be a nofix. The current mechanism to select the 'best' compression algorithm [0] does not allow for a fallback on 404. Otoh changing the priority might as well break other setups.

Possible solution:
If you mirror those repositories on a local storage, it might be possible to recompress the Packages files yourself, and with the right parameters, they should end up being bit for bit compatible.

[0] https://github.com/sassoftware/python-debpkgr/blob/220d57b461c2f323a30fb44b2d1126ca4a0f9ea6/debpkgr/aptrepo.py#L267

Sorry for late response.
I understad, I think the best solution for us is to phase out the old machines instead

Thanks!

Actions

Copy link