| Summary: | app-arch/createrepo-0.9.8-r1 removal ( was app-arch/createrepo-0.9.8-r1 crashes after indexing ~30 rpms ) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Carpentier <carpentier.pf> |
| Component: | Current packages | Assignee: | Gentoo TreeCleaner Project <treecleaner> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alon.barlev, idella4, miska, python |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
createrepo-0.9.9.ebuild.diff
deltarpm-9999.ebuild.diff deltarpm-3.6_pre20110223.ebuild 3.6_pre20110223-build.patch |
||
Candidate for removal? Lastriting it sounds fine to me. I use this package on my Gentoo system and it works just fine. I just ran a simular test on my x86_64 box against a repo that contained the same openoffice package and things worked file. Is there a way I can step up to the plate to maintain this package and keep it in Gentoo? (In reply to comment #3) > I use this package on my Gentoo system and it works just fine. I just ran a > simular test on my x86_64 box against a repo that contained the same > openoffice package and things worked file. Is there a way I can step up to > the plate to maintain this package and keep it in Gentoo? Have a look here http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml I use this for creating rhel media on gentoo. Works correctly. Please don't remove. Is anyone willing to maintain this? (In reply to comment #6) > Is anyone willing to maintain this? Support current functionality, same as in centos and friends... no patches or any Gentoo specific code... (In reply to comment #7) > (In reply to comment #6) > > Is anyone willing to maintain this? > > Support current functionality, same as in centos and friends... no patches > or any Gentoo specific code... The problem comes when a package doesn't have a downstream maintainer (looks like current people in metadata.xml are no longer interested in it) and a bug is kept unfixed (and upstream dead). In this case looks like we could try to bump it to 0.9.9 version and check patches applied by fedora and opensuse... but I would like to this being checked and prepared by a future proxy maintainer (I can later commit and be your proxy if you want): http://download.opensuse.org/factory/repo/src-oss/suse/src/createrepo-0.9.9-1.1.src.rpm http://pkgs.fedoraproject.org/gitweb/?p=createrepo.git;a=blob;f=createrepo.spec;h=2a7e7e38ba18f07c411e1c795588cbc71959f802;hb=HEAD (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > Is anyone willing to maintain this? > > > > Support current functionality, same as in centos and friends... no patches > > or any Gentoo specific code... > > The problem comes when a package doesn't have a downstream maintainer (looks > like current people in metadata.xml are no longer interested in it) and a > bug is kept unfixed (and upstream dead). > > In this case looks like we could try to bump it to 0.9.9 version and check > patches applied by fedora and opensuse... but I would like to this being > checked and prepared by a future proxy maintainer (I can later commit and be > your proxy if you want): > http://download.opensuse.org/factory/repo/src-oss/suse/src/createrepo-0.9.9- > 1.1.src.rpm > http://pkgs.fedoraproject.org/gitweb/?p=createrepo.git;a=blob;f=createrepo. > spec;h=2a7e7e38ba18f07c411e1c795588cbc71959f802;hb=HEAD Did any one checked that new version? (In reply to comment #9) > Did any one checked that new version? I will do this today or tomorrow. Created attachment 311697 [details, diff]
createrepo-0.9.9.ebuild.diff
Created attachment 311699 [details, diff]
deltarpm-9999.ebuild.diff
Patches for the createrepo are as-is from[1] I had to use the live ebuild of detarpm as found nowhere the 3.6 version sources redhat uses... I did not invest much in installing the python poerly... the makefile is living hell in term of python module build. Anyway, it is working for me... [1] http://pkgs.fedoraproject.org/gitweb/?p=createrepo.git;a=tree;hb=HEAD Created attachment 311719 [details]
deltarpm-3.6_pre20110223.ebuild
This ebuild is for installing exactly the same 3.6 git snapshot used by fedora... but I am unable to make python part comply LDFLAGS :S
And the same occurs with 9999 :( (In reply to comment #15) > And the same occurs with 9999 :( I will take care of this. Created attachment 311775 [details, diff]
3.6_pre20110223-build.patch
This should apply ldflags to python module as well.
+*deltarpm-3.6_pre20110223 (15 May 2012) + + 15 May 2012; Pacho Ramos <pacho@gentoo.org> +deltarpm-3.6_pre20110223.ebuild, + +files/3.6_pre20110223-build.patch, -deltarpm-3.5.ebuild: + Version bump (using Fedora snapshot) and remove old. Thanks a lot to Alon Bar- + Lev for his help (#396067). + +*createrepo-0.9.9 (15 May 2012) + + 15 May 2012; Pacho Ramos <pacho@gentoo.org> +createrepo-0.9.9.ebuild, + +files/createrepo-0.9.9-ten-changelog-limit.patch, + -createrepo-0.9.7-r1.ebuild, -createrepo-0.9.7.ebuild, + -createrepo-0.9.8-r1.ebuild, -createrepo-0.9.8.ebuild, metadata.xml: + Version bump that should fix crash reported in bug #396067 by Carpentier. + Thanks a lot to Alon Bar-Lev for his work, he also becames its maintainer with + me as proxy. Remove old. + |
createrepo crashes after indexing ~30 rpms. Bug seen on x86_64 and ppc64. Reproducible: Always Steps to Reproduce: 1. createrepo REPODIR 2. error Actual Results: 32/4140 - openoffice.org-testtools-3.2.1-19.6.el6.x86_64.rpm Traceback (most recent call last): File "/usr/share/createrepo/genpkgmetadata.py", line 249, in <module> main(sys.argv[1:]) File "/usr/share/createrepo/genpkgmetadata.py", line 223, in main mdgen.doPkgMetadata() File "/usr/lib64/python2.7/site-packages/createrepo/__init__.py", line 367, in doPkgMetadata self.writeMetadataDocs(packages) File "/usr/lib64/python2.7/site-packages/createrepo/__init__.py", line 534, in writeMetadataDocs clog_limit=self.conf.changelog_limit)) File "/usr/lib64/python2.7/site-packages/yum/packages.py", line 1271, in xml_dump_other_metadata msg += "%s\n</package>\n" % misc.to_unicode(self._dump_changelog(clog_limit)) File "/usr/lib64/python2.7/site-packages/yum/packages.py", line 1230, in _dump_changelog if not self.changelog: File "/usr/lib64/python2.7/site-packages/yum/packages.py", line 625, in <lambda> changelog = property(fget=lambda self: self.returnChangelog()) File "/usr/lib64/python2.7/site-packages/yum/packages.py", line 1443, in returnChangelog misc.to_unicode(self.hdr['changelogtext'], errors='replace')) TypeError: zip argument #1 must support iteration Expected Results: repodata created commenting everything in def returnChangelog(self) (inside /usr/lib64/python2.7/site-packages/yum/packages.py) makes it works. (Dirty patch) def returnChangelog(self): # note - if we think it is worth keeping changelogs in memory # then create a _loadChangelog() method to put them into the # self._changelog attr #if len(self.hdr['changelogname']) > 0: # return zip(misc.to_unicode(self.hdr['changelogtime'], errors='replace'), # misc.to_unicode(self.hdr['changelogname'], errors='replace'), # misc.to_unicode(self.hdr['changelogtext'], errors='replace')) return []