Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1271010

Summary:	spacewalk-repo-sync - unpack requires a string argument of length 4
Product:	[Community] Spacewalk	Reporter:	Jim Howland <jim.howland>
Component:	Server	Assignee:	Jiří Dostál <jdostal>
Status:	CLOSED NOTABUG	QA Contact:	Red Hat Satellite QA List <satqe-list>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	2.4	CC:	jdostal, jim.howland
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-01-04 21:46:09 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1484117

Description Jim Howland 2015-10-12 22:26:43 UTC

Description of problem:
When syncing certain channels spacewalk-repo-sync throws an error on every package :
unpack requires a string argument of length 4

Version-Release number of selected component (if applicable):
Spacewalk 2.4

How reproducible:
Everytime - I tried to exclude the java package as that seemed to be causing the issue but even the exclude seemed to fail (see below)

Steps to Reproduce:
See command in actual results

Actual results:
spacewalk_server:/root]> spacewalk-repo-sync --type=yum --url='http://mirrorlist.centos.org/?release=5&arch=x86_64&repo=updates' --channel='centos5-x86_64-updates' -e java-1.7.0-openjdk-devel-1.7.0.79-2.5.5.2.el5
======================================
| Channel: centos5-x86_64-updates
======================================

Repo URL: http://mirrorlist.centos.org/?release=5&arch=x86_64&repo=updates
Packages in repo:               518
Packages already synced:         68
Packages to sync:               450
1/450 : php-bcmath-5.1.6-45.el5_11-0.x86_64
2/450 : kernel-debug-2.6.18-400.el5-0.x86_64
3/450 : mysql55-mysql-test-5.5.45-1.el5-0.x86_64
4/450 : java-1.7.0-openjdk-devel-1.7.0.79-2.5.5.2.el5_11-1.x86_64
5/450 : zsh-html-4.2.6-6.el5-0.x86_64
unpack requires a string argument of length 4
6/450 : bind-sdb-9.3.6-25.P1.el5_11.3-30.x86_64
unpack requires a string argument of length 4
7/450 : nss-tools-3.16.1-4.el5_11-0.x86_64
unpack requires a string argument of length 4
8/450 : popt-1.10.2.3-36.el5_11-0.i386
unpack requires a string argument of length 4
9/450 : firefox-31.5.0-1.el5.centos-0.i386
unpack requires a string argument of length 4
10/450 : openldap-clients-2.3.43-29.el5_11-0.x86_64
unpack requires a string argument of length 4


etc etc until package 450 is reached.

Expected results:
The packages would be sync'd.

Additional info:

Comment 1 Jiří Dostál 2015-11-23 14:50:03 UTC

Hello Jim,

could you please provide me information about your Python version? I was unsuccessful reproducing this issue so far. 
What OS are you using?

Regards,
Jiri

Comment 2 Jim Howland 2015-12-30 23:38:53 UTC

Hi Jiri

Sincere apologies for not getting back to you sooner. We've been migrating from SW v1.9 to SW 2.4 and haven't had time to answer your question. I'm still getting the error. I'm running CentOS 6.7 x86_64.

The Python version is the standard one with the release:

python -V
Python 2.6.6

Regards
Jim

Comment 3 Jim Howland 2016-01-04 00:04:35 UTC

I've also tried Python v3.5 but that fails all over the place. I'm about to try v2.7 to see if this gives any joy!

Comment 4 Jim Howland 2016-01-04 04:49:15 UTC

I've managed to get it to work by excluding the Java packages :

spacewalk-repo-sync --type=yum --url='http://mirrorlist.centos.org/?release=5&arch=x86_64&repo=updates' --channel='centos5-x86_64-updates' -e java-1.7.0-openjdk-devel,java-1.6.0-openjdk-javadoc,java-1.6.0-openjdk-devel,java-1.6.0-openjdk,java-1.7.0-openjdk-javadoc,java-1.6.0-openjdk-devel

I haven't tried Python v2.7 yet - that is my next step.

Comment 5 Jim Howland 2016-01-04 21:44:31 UTC

I've found this is because of our Proxy. If we send via our Cisco IronPorts on port 3128 we get these failures on large packages. If we send via a squid proxy on port 8080 it work fine. I'll close the Bugzilla.

Comment 6 Eric Herget 2017-09-28 18:09:29 UTC

This BZ closed some time during 2.5, 2.6 or 2.7.  Adding to 2.7 tracking bug.