Hide Forgot
Created attachment 1032080 [details] Error with original packages file for jessie main (binary-amd64) Description of problem: The "Packages.gz" file created by spacewalk is slightly wrong formated, so that a this file is not parseable by Debian systems. Version-Release number of selected component (if applicable): 2.2 (also tested with 2.3) How reproducible: always Steps to Reproduce: 1. Sync all debian 8 packages of "main" (binary-amd64) into a spacewalk channel 2. Install a debian 8 client and manually register it to spacewalk and add channel to client 3. Run "apt-get update" (twice). Very first run after registration ok Actual results: see attachment apt-get_update_error_jessie.txt Expected results: No errors while parsing Packages.gz file Additional info: It turns out, that there is a space character missing within the parenthesis where the package version is listed. Example: Wrong "Depends" line of package "games-sport" (mentioned in attachment) Depends: games-tasks (=1) RIGHT "Depends" line (from original Debian Packages.gz) Depends: games-tasks (= 1) <== Space (" ") between operator and version string. Temporary Workaround: Modify the generated Packages file with sed -e 's#(\([<>=]*\)\([^)]*\))#(\1 \2)#g' Packages | gzip -c > Packages.gz Solution: Just add a space between the operator and the version. I followed the source until this file (funktion addPackageDebData) https://github.com/spacewalkproject/spacewalk/blob/20dea1b0c8ba20e8e1663cff0d92f9795b3d54cd/java/code/src/com/redhat/rhn/taskomatic/task/repomd/DebPackageWriter.java Regards, Robert
Note: it looks the package capabilities are parsed incorrectly. I suppose, the operator should not be a part of the version entry: # select * from rhnPackageCapability where version like '>%'; id | name | version | created | modified ---------+---------+---------+-------------------------------+------------------------------- 5961575 | libc6_0 | >=2.7 | 2015-06-01 10:38:42.641241+02 | 2015-06-01 10:38:42.641241+02
Then there should either be another field within the DB to hold the operator or - meybe easier, the operator and version be separated with a " " When I read the code right, then the "deb822.py" file in /usr/lib/python2.6/site-packages/debian writes the version string correct. ... def str(rels): """Format to string structured inter-package relationships Perform the inverse operation of parse_relations, returning a string suitable to be written in a package stanza. """ def pp_arch(arch_spec): (excl, arch) = arch_spec if excl: return arch else: return '!' + arch def pp_atomic_dep(dep): s = dep['name'] if dep.get('version') is not None: s += ' (%s %s)' % dep['version'] if dep.get('arch') is not None: s += ' [%s]' % ' '.join(map(pp_arch, dep['arch'])) return s pp_or_dep = lambda deps: ' | '.join(map(pp_atomic_dep, deps)) return ', '.join(map(pp_or_dep, rels)) So the "space" character seems to be stripped away somewhere else. Regards, Robert
(In reply to Robert Paschedag from comment #2) > Then there should either be another field within the DB to hold the operator There is. See: schema/spacewalk/common/tables/rhnPackageBreaks.sql schema/spacewalk/common/tables/rhnPackageConflicts.sql schema/spacewalk/common/tables/rhnPackageEnhances.sql schema/spacewalk/common/tables/rhnPackageObsoletes.sql schema/spacewalk/common/tables/rhnPackagePredepends.sql schema/spacewalk/common/tables/rhnPackageProvides.sql schema/spacewalk/common/tables/rhnPackageRecommends.sql schema/spacewalk/common/tables/rhnPackageRequires.sql schema/spacewalk/common/tables/rhnPackageSuggests.sql schema/spacewalk/common/tables/rhnPackageSupplements.sql it's the 'sense' column. That's why I suppose, the debian package capabilities get incorrectly parsed. (It's possible, they're written incorrectly as well, but the primary issue I see here is the parsing.)
Made a pull request to introduce a workaround (not a real fix) that just puts a space character between the operator and the version number if an operator is found within a "version" string. Only when generating the Packages.gz file. https://github.com/spacewalkproject/spacewalk/pull/266 Regards, Robert
I can confirm this workaround works and would like to see this merged until a proper fix is found. Regards, Dirk
Another attempt to fix this bug: https://github.com/spacewalkproject/spacewalk/pull/399
Spacewalk 2.8 (and older) has already reached it's End Of Life. Thank you for reporting this issue and we are sorry that we were not able to fix it before end of life. If you would still like to see this bug fixed and are able to reproduce it against current version of Spacewalk 2.9, you are encouraged change the 'version' and re-open it.