From kanarip at kanarip.com Sun Mar 1 15:00:58 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 01 Mar 2009 16:00:58 +0100 Subject: Revisor (or Anaconda?) spin - unable to install on i586 In-Reply-To: <46a038f90902261201u2d67497cv6e6c303f3810ad20@mail.gmail.com> References: <46a038f90902141358h4ac9c4a9sad175a6147a968dc@mail.gmail.com> <46a038f90902151601g54ca414dn66de3a4bef214f39@mail.gmail.com> <4998C6C8.70103@kanarip.com> <46a038f90902151806h50595dd4r8152baab33bddc2b@mail.gmail.com> <4999757B.1000001@kanarip.com> <46a038f90902222248o436d2602oe330aeab5cde6fb6@mail.gmail.com> <49A29375.9090709@kanarip.com> <46a038f90902231812x7fea068du5e58aee0b512bfb7@mail.gmail.com> <46a038f90902251938n6934e399x7e5f527982d9035@mail.gmail.com> <49A656E3.9060304@kanarip.com> <46a038f90902261201u2d67497cv6e6c303f3810ad20@mail.gmail.com> Message-ID: <49AAA32A.9010908@kanarip.com> Martin Langhoff wrote: > On Thu, Feb 26, 2009 at 9:46 PM, Jeroen van Meeuwen wrote: >> If I gave you some 2.1.4 revisor packages to test on Fedora 9 (I'm not sure >> they work but there have been no major changes), are you able to test them? > > Yes. My only 'compat' concern is with anaconda. If they expect > anaconda smarts that aren't there... > Well, Revisor (by means of the version-specific buildinstall scripts in /usr/lib/revisor/scripts/) on Fedora 10 is able to compose Fedora 9, and only changes in things -like squashfs major version mismatches (like right now between a Fedora 9+ and an EL-5 station) may cause issues. The Revisor version itself... shouldn't cause all that many issues. If you want a quick try you can do: autoreconf -v && ./configure && make rpm in the source tree. Kind regards, Jeroen van Meeuwen -kanarip From schubert at jla.rutgers.edu Mon Mar 2 22:25:56 2009 From: schubert at jla.rutgers.edu (Brian Schubert) Date: Mon, 02 Mar 2009 17:25:56 -0500 Subject: koji 1.3.0 In-Reply-To: <499CAD0A.9090602@redhat.com> References: <499CAD0A.9090602@redhat.com> Message-ID: <49AC5CF4.70905@jla.rutgers.edu> Hi, Is there an easy way to convert the database from Koji 1.2.6 to work with this new release? Importing the initial packages took a very long time, and as such, starting with a fresh database is undesirable. Or has the import speed improved drastically with this release? Thanks, -Brian Schubert Mike McLean wrote: > The tarball is posted here: > https://fedorahosted.org/koji/wiki/KojiRelease > (created from koji-1.3.0 tag) > > > Major Changes > -------------- > Support for external repos > new cli commands > createrepo tasks now have a higher weight > Support for noarch subpackages > Support larger hashes > Handle different kinds of rpm signatures [mitr] (#127) > support file digests other than md5 in the api and web UI > Hub configuration via hub.conf > use a hub config file instead of PythonOptions > scan for handlers once at startup instead of each call > now honors KojiDir > Remove huge tables from db > - rpmfiles, rpmdeps and changelog tables dropped > - data pulled from rpms as needed > Build srpms in chroots > bump the weight of buildSRPMFromSCM > Some web ui theming support > SiteName option (the name that shows up in the title) > move explicit image sizes to css > make welcome message customizable > Improved security > add an auth token to defend against CSRF > include the current time in the cookie > some changes to the web UI to defend against XSS > Hub policies > configured in hub.conf > enable verbose policy errors without full debug > current policies: > tag: controls tag, untag, move operations > build_from_srpm: controls whether such builds are allowed > build_from_repo_id: controls whether such builds are allowed > Plugin support > kojihub and kojid now have limited plugin support > > > Other Changes > ------------- > Python-2.6-isms > use hashlib if available > use subprocess instead of popen2 > Builder > improved task cleanup > check the load average before taking a task > make use of createrepo --update optional > choose a better arch for noarch builds > update the buildArch task weight based on the average duration of > a build > of the package > set %distribution the same way we set %vendor and %packager > cleanup before re-taking a freed or reassigned task > indicate which log people should look in for build failures > make use of --skip-stat configurable > use same repo for all buildArch subtasks > more fully honor topdir option > Web UI > show summary and description for rpms and builds > group rpms more sensibly (make the build log links correct) > remove the dirtyness indicator from the buildrootinfo page (never > used) > enable displaying of only the latest builds in a tag > use ids instead of names in the urls > fix the "Watch logs" feature in the web UI to work over SSL > cache compiled Cheetah templates > update the web UI to conform to XHTML 1.0 Transitional > tasks page: rework view selector > use kojiweb.publisher (new location) > Hub > NotifyOnSuccess option > honor KojiDir option > DisableNotifications option > don't blow up when the database contains older base64 encoded task > data > make a latest link when a new repo completes > add createdBefore= and createdAfter= parameters to listBuilds() > fix LoginCreatesUser check > in resetBuild use CANCELED state instead of FAILED > report offline status if: > db connection fails > there are errors on startup > preserve old extra_arches during package list updates > Command line > new subcommand: search > new subcommand: regen-repo > new subcommand: remove-tag > show package filters correctly in taginfo > allow list-tagged to query at an event > added --non-latest to untag-pkg subcommand > added --old-user flag to set-pkg-owner-global subcommand > show buildroot info in rpminfo output > show arch in list-buildroot output > handle chain-build cases where the build tag is the same as the > dest tag > Utils > don't start kojira by default (#96) > fix timestamp checks when deleting repos > package koji-gc > added purge option to koji-gc > added koji-shadow utility for shadow builds > Changes related to shadow builds > koji-shadow utility > allow creation of repos from a specified event > allow building from a specific repo id (subject to policy) > Miscellaneous > add a strict option to multiCall() > handle empty multicalls sensibly > return a placeholder object while in a multicall > enable building Koji from the Koji git repo with Koji [Jeffrey C. > Ollie] > > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From mikeb at redhat.com Mon Mar 2 22:31:48 2009 From: mikeb at redhat.com (Mike Bonnet) Date: Mon, 02 Mar 2009 17:31:48 -0500 Subject: koji 1.3.0 In-Reply-To: <49AC5CF4.70905@jla.rutgers.edu> References: <499CAD0A.9090602@redhat.com> <49AC5CF4.70905@jla.rutgers.edu> Message-ID: <49AC5E54.2070009@redhat.com> Brian Schubert wrote: > Hi, > > Is there an easy way to convert the database from Koji 1.2.6 to work > with this new release? > > Importing the initial packages took a very long time, and as such, > starting with a fresh database is undesirable. Or has the import speed > improved drastically with this release? There is an upgrade script (/usr/share/doc/koji-1.3.1/docs/schema-upgrade-1.2-1.3.sql) to upgrade an existing database the 1.3 format. Note that the external repos support may allow you to avoid an initial import altogether, in many cases. There is documentation forthcoming on how to setup external repos. In the meantime you can ask questions in #koji on Freenode. > Thanks, > > -Brian Schubert > > Mike McLean wrote: >> The tarball is posted here: >> https://fedorahosted.org/koji/wiki/KojiRelease >> (created from koji-1.3.0 tag) >> >> >> Major Changes >> -------------- >> Support for external repos >> new cli commands >> createrepo tasks now have a higher weight >> Support for noarch subpackages >> Support larger hashes >> Handle different kinds of rpm signatures [mitr] (#127) >> support file digests other than md5 in the api and web UI >> Hub configuration via hub.conf >> use a hub config file instead of PythonOptions >> scan for handlers once at startup instead of each call >> now honors KojiDir >> Remove huge tables from db >> - rpmfiles, rpmdeps and changelog tables dropped >> - data pulled from rpms as needed >> Build srpms in chroots >> bump the weight of buildSRPMFromSCM >> Some web ui theming support >> SiteName option (the name that shows up in the title) >> move explicit image sizes to css >> make welcome message customizable >> Improved security >> add an auth token to defend against CSRF >> include the current time in the cookie >> some changes to the web UI to defend against XSS >> Hub policies >> configured in hub.conf >> enable verbose policy errors without full debug >> current policies: >> tag: controls tag, untag, move operations >> build_from_srpm: controls whether such builds are allowed >> build_from_repo_id: controls whether such builds are allowed >> Plugin support >> kojihub and kojid now have limited plugin support >> >> >> Other Changes >> ------------- >> Python-2.6-isms >> use hashlib if available >> use subprocess instead of popen2 >> Builder >> improved task cleanup >> check the load average before taking a task >> make use of createrepo --update optional >> choose a better arch for noarch builds >> update the buildArch task weight based on the average duration of >> a build >> of the package >> set %distribution the same way we set %vendor and %packager >> cleanup before re-taking a freed or reassigned task >> indicate which log people should look in for build failures >> make use of --skip-stat configurable >> use same repo for all buildArch subtasks >> more fully honor topdir option >> Web UI >> show summary and description for rpms and builds >> group rpms more sensibly (make the build log links correct) >> remove the dirtyness indicator from the buildrootinfo page (never >> used) >> enable displaying of only the latest builds in a tag >> use ids instead of names in the urls >> fix the "Watch logs" feature in the web UI to work over SSL >> cache compiled Cheetah templates >> update the web UI to conform to XHTML 1.0 Transitional >> tasks page: rework view selector >> use kojiweb.publisher (new location) >> Hub >> NotifyOnSuccess option >> honor KojiDir option >> DisableNotifications option >> don't blow up when the database contains older base64 encoded task >> data >> make a latest link when a new repo completes >> add createdBefore= and createdAfter= parameters to listBuilds() >> fix LoginCreatesUser check >> in resetBuild use CANCELED state instead of FAILED >> report offline status if: >> db connection fails >> there are errors on startup >> preserve old extra_arches during package list updates >> Command line >> new subcommand: search >> new subcommand: regen-repo >> new subcommand: remove-tag >> show package filters correctly in taginfo >> allow list-tagged to query at an event >> added --non-latest to untag-pkg subcommand >> added --old-user flag to set-pkg-owner-global subcommand >> show buildroot info in rpminfo output >> show arch in list-buildroot output >> handle chain-build cases where the build tag is the same as the >> dest tag >> Utils >> don't start kojira by default (#96) >> fix timestamp checks when deleting repos >> package koji-gc >> added purge option to koji-gc >> added koji-shadow utility for shadow builds >> Changes related to shadow builds >> koji-shadow utility >> allow creation of repos from a specified event >> allow building from a specific repo id (subject to policy) >> Miscellaneous >> add a strict option to multiCall() >> handle empty multicalls sensibly >> return a placeholder object while in a multicall >> enable building Koji from the Koji git repo with Koji [Jeffrey C. >> Ollie] >> >> >> -- >> Fedora-buildsys-list mailing list >> Fedora-buildsys-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From chenbaozi at gmail.com Fri Mar 13 07:21:03 2009 From: chenbaozi at gmail.com (=?UTF-8?B?6ZmI6bKN5a2c?=) Date: Fri, 13 Mar 2009 15:21:03 +0800 Subject: epel mock-0.9.14 problem Message-ID: hello, I was trying mock-0.9.14 in EPEL on CentOS 5.2. It seems it has got something wrong. Since there is no buildsys-build package in CentOS repository, it reports the error "Could not find useradd in chroot, maybe the install failed?". So I add those buildsys-build, buildsys-macro and rpmdevtools packages into the repository, and it results: ERROR: Command failed: # /usr/bin/yum --installroot /var/lib/mock/centos/root/ install buildsys-build Traceback (most recent call last): File "/usr/bin/yum", line 29, in ? yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 229, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 145, in main (result, resultmsgs) = base.buildTransaction() File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 647, in buildTransaction (rescode, restring) = self.resolveDeps() File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 696, in resolveDeps CheckDeps, checkinstalls, checkremoves, missing = self._resolveRequires(errors) File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 779, in _resolveRequires thisneeds = self._checkInstall(txmbr) File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 851, in _checkInstall provs = self.tsInfo.getProvides(*req) File "/usr/lib/python2.4/site-packages/yum/transactioninfo.py", line 432, in getProvides result.update(self.getNewProvides(name, flag, version)) File "/usr/lib/python2.4/site-packages/yum/transactioninfo.py", line 414, in getNewProvides for pkg, hits in self.pkgSack.getProvides(name, flag, version).iteritems(): File "/usr/lib/python2.4/site-packages/yum/packageSack.py", line 300, in getProvides return self._computeAggregateDictResult("getProvides", name, flags, version) File "/usr/lib/python2.4/site-packages/yum/packageSack.py", line 470, in _computeAggregateDictResult sackResult = apply(method, args) File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 861, in getProvides return self._search("provides", name, flags, version) File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 43, in newFunc return func(*args, **kwargs) File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 837, in _search for pkg in self.searchFiles(name, strict=True): File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 43, in newFunc return func(*args, **kwargs) File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 586, in searchFiles self._sql_pkgKey2po(rep, cur, pkgs) File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 470, in _sql_pkgKey2po pkg = self._packageByKey(repo, ob['pkgKey']) File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 413, in _packageByKey po = self.pc(repo, cur.fetchone()) File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 68, in __init__ self._read_db_obj(db_obj) File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 94, in _read_db_obj setattr(self, item, _share_data(db_obj[item])) TypeError: unsubscriptable object -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiteshs at marvell.com Fri Mar 13 11:14:10 2009 From: jiteshs at marvell.com (Jitesh Shah) Date: Fri, 13 Mar 2009 16:44:10 +0530 Subject: epel mock-0.9.14 problem In-Reply-To: References: Message-ID: <1236942850.9228.0.camel@localhost.localdomain> I suppose the "useradd" binary is in shadow-utils package? Try including the shadow-utils package in the build group. Jitesh On Fri, 2009-03-13 at 15:21 +0800, ??? wrote: > hello, I was trying mock-0.9.14 in EPEL on CentOS 5.2. It seems it has > got something wrong. Since there is no buildsys-build package in > CentOS repository, it reports the error "Could not find useradd in > chroot, maybe the install failed?". So I add those buildsys-build, > buildsys-macro and rpmdevtools packages into the repository, and it > results: > > ERROR: Command failed: > # /usr/bin/yum --installroot /var/lib/mock/centos/root/ install > buildsys-build > Traceback (most recent call last): > File "/usr/bin/yum", line 29, in ? > yummain.user_main(sys.argv[1:], exit_code=True) > File "/usr/share/yum-cli/yummain.py", line 229, in user_main > errcode = main(args) > File "/usr/share/yum-cli/yummain.py", line 145, in main > (result, resultmsgs) = base.buildTransaction() > File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 647, > in buildTransaction > (rescode, restring) = self.resolveDeps() > File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 696, > in resolveDeps > CheckDeps, checkinstalls, checkremoves, missing = > self._resolveRequires(errors) > File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 779, > in _resolveRequires > thisneeds = self._checkInstall(txmbr) > File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 851, > in _checkInstall > provs = self.tsInfo.getProvides(*req) > File "/usr/lib/python2.4/site-packages/yum/transactioninfo.py", line > 432, in getProvides > result.update(self.getNewProvides(name, flag, version)) > File "/usr/lib/python2.4/site-packages/yum/transactioninfo.py", line > 414, in getNewProvides > for pkg, hits in self.pkgSack.getProvides(name, flag, > version).iteritems(): > File "/usr/lib/python2.4/site-packages/yum/packageSack.py", line > 300, in getProvides > return self._computeAggregateDictResult("getProvides", name, > flags, version) > File "/usr/lib/python2.4/site-packages/yum/packageSack.py", line > 470, in _computeAggregateDictResult > sackResult = apply(method, args) > File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 861, > in getProvides > return self._search("provides", name, flags, version) > File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 43, > in newFunc > return func(*args, **kwargs) > File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 837, > in _search > for pkg in self.searchFiles(name, strict=True): > File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 43, > in newFunc > return func(*args, **kwargs) > File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 586, > in searchFiles > self._sql_pkgKey2po(rep, cur, pkgs) > File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 470, > in _sql_pkgKey2po > pkg = self._packageByKey(repo, ob['pkgKey']) > File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 413, > in _packageByKey > po = self.pc(repo, cur.fetchone()) > File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 68, > in __init__ > self._read_db_obj(db_obj) > File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 94, > in _read_db_obj > setattr(self, item, _share_data(db_obj[item])) > TypeError: unsubscriptable object > > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From chenbaozi at gmail.com Fri Mar 13 14:45:44 2009 From: chenbaozi at gmail.com (=?UTF-8?B?6ZmI6bKN5a2c?=) Date: Fri, 13 Mar 2009 22:45:44 +0800 Subject: epel mock-0.9.14 problem In-Reply-To: <1236942850.9228.0.camel@localhost.localdomain> References: <1236942850.9228.0.camel@localhost.localdomain> Message-ID: I finally made it. Besides there must be an buildsys-build packages in the repo, the error comes from the wrong mock configuration, which do not have the [base] repo name. After add the [base] repo into 'yum.conf' options, everything goes well. But it seem that the repo name [base] is not necessary when I use yum outside mock. On Fri, Mar 13, 2009 at 7:14 PM, Jitesh Shah wrote: > I suppose the "useradd" binary is in shadow-utils package? Try including > the shadow-utils package in the build group. > > Jitesh > > > On Fri, 2009-03-13 at 15:21 +0800, ??? wrote: > > hello, I was trying mock-0.9.14 in EPEL on CentOS 5.2. It seems it has > > got something wrong. Since there is no buildsys-build package in > > CentOS repository, it reports the error "Could not find useradd in > > chroot, maybe the install failed?". So I add those buildsys-build, > > buildsys-macro and rpmdevtools packages into the repository, and it > > results: > > > > ERROR: Command failed: > > # /usr/bin/yum --installroot /var/lib/mock/centos/root/ install > > buildsys-build > > Traceback (most recent call last): > > File "/usr/bin/yum", line 29, in ? > > yummain.user_main(sys.argv[1:], exit_code=True) > > File "/usr/share/yum-cli/yummain.py", line 229, in user_main > > errcode = main(args) > > File "/usr/share/yum-cli/yummain.py", line 145, in main > > (result, resultmsgs) = base.buildTransaction() > > File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 647, > > in buildTransaction > > (rescode, restring) = self.resolveDeps() > > File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 696, > > in resolveDeps > > CheckDeps, checkinstalls, checkremoves, missing = > > self._resolveRequires(errors) > > File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 779, > > in _resolveRequires > > thisneeds = self._checkInstall(txmbr) > > File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 851, > > in _checkInstall > > provs = self.tsInfo.getProvides(*req) > > File "/usr/lib/python2.4/site-packages/yum/transactioninfo.py", line > > 432, in getProvides > > result.update(self.getNewProvides(name, flag, version)) > > File "/usr/lib/python2.4/site-packages/yum/transactioninfo.py", line > > 414, in getNewProvides > > for pkg, hits in self.pkgSack.getProvides(name, flag, > > version).iteritems(): > > File "/usr/lib/python2.4/site-packages/yum/packageSack.py", line > > 300, in getProvides > > return self._computeAggregateDictResult("getProvides", name, > > flags, version) > > File "/usr/lib/python2.4/site-packages/yum/packageSack.py", line > > 470, in _computeAggregateDictResult > > sackResult = apply(method, args) > > File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 861, > > in getProvides > > return self._search("provides", name, flags, version) > > File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 43, > > in newFunc > > return func(*args, **kwargs) > > File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 837, > > in _search > > for pkg in self.searchFiles(name, strict=True): > > File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 43, > > in newFunc > > return func(*args, **kwargs) > > File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 586, > > in searchFiles > > self._sql_pkgKey2po(rep, cur, pkgs) > > File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 470, > > in _sql_pkgKey2po > > pkg = self._packageByKey(repo, ob['pkgKey']) > > File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 413, > > in _packageByKey > > po = self.pc(repo, cur.fetchone()) > > File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 68, > > in __init__ > > self._read_db_obj(db_obj) > > File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 94, > > in _read_db_obj > > setattr(self, item, _share_data(db_obj[item])) > > TypeError: unsubscriptable object > > > > > > -- > > Fedora-buildsys-list mailing list > > Fedora-buildsys-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chenbaozi at gmail.com Sun Mar 15 09:55:48 2009 From: chenbaozi at gmail.com (=?UTF-8?B?6ZmI6bKN5a2c?=) Date: Sun, 15 Mar 2009 17:55:48 +0800 Subject: how to build srpms on koji? Message-ID: Hi, After long time fighting with koji configuration, I think the service is now running successfully. I added some srpms to it and saw its information on kojiweb. But it seems I can not build the srpms by koji (when I submit a build task to koji, it will "open" for a while, then it would finally come to be failed). I doubted if I have missed some configurations which connecting koji and mock. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at traylen.net Sun Mar 15 11:45:57 2009 From: steve at traylen.net (Steve Traylen) Date: Sun, 15 Mar 2009 12:45:57 +0100 Subject: mergerepo fails with PCDATA invalid Char value 8 Message-ID: Hi, Got koji basically working for me over the last couple of weeks. Was very keen to try its new external repository support. Starting with a fresh instance I made a tag (dist-slc5) containing two repos. koji add-external-repo -t dist-slc5 -p 10 "slc5-64-base" http://linuxsoft.cern.ch/cern/slc5X/x86_64/yum/os koji add-external-repo -t dist-slc5 -p 10 "slc5-32-base" http://linuxsoft.cern.ch/cern/slc5X/i386/yum/os and then tried to make a koji repo from that. koji regen-repo dist-slc5 This called /usr/libexec/kojid/mergerepos -a i386 -b /mnt/koji/repos/dist-slc5-build/189/i386/blocklist -o /tmp/koji/tasks/556/556/repo \ -g /mnt/koji/repos/dist-slc5-build/189/groups/comps.xml -r http://linuxsoft.cern.ch/cern/slc5X/x86_64/yum/os/ \ -r http://linuxsoft.cern.ch/cern/slc5X/i386/yum/os/ resulting in as below. Any ideas ? Steve process:19630): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: Parsing other.xml error: PCDATA invalid Char value 8 Traceback (most recent call last): File "/usr/libexec/kojid/mergerepos", line 241, in main(sys.argv[1:]) File "/usr/libexec/kojid/mergerepos", line 236, in main merge.write_metadata() File "/usr/libexec/kojid/mergerepos", line 216, in write_metadata mdgen.doPkgMetadata() File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line 332, in doPkgMetadata self.writeMetadataDocs(packages) File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line 475, in writeMetadataDocs clog_limit=self.conf.changelog_limit)) File "/usr/lib/python2.5/site-packages/yum/packages.py", line 959, in xml_dump_other_metadata msg += "%s\n\n" % misc.to_unicode(self._dump_changelog(clog_limit)) File "/usr/lib/python2.5/site-packages/yum/packages.py", line 927, in _dump_changelog if not self.changelog: File "/usr/lib/python2.5/site-packages/yum/packages.py", line 423, in changelog = property(fget=lambda self: self.returnChangelog()) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 225, in returnChangelog self._loadChangelog() File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 202, in _loadChangelog self.sack.populate(self.repo, mdtype='otherdata') File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 184, in populate dobj = repo_cache_function(xml, csum) File "/usr/lib/python2.5/site-packages/sqlitecachec.py", line 60, in getOtherdata self.repoid)) TypeError: Parsing other.xml error: PCDATA invalid Char value 8 Steve -- Steve Traylen -------------- next part -------------- A non-text attachment was scrubbed... Name: mergerepo.log Type: text/x-log Size: 3392 bytes Desc: not available URL: From steve at traylen.net Sun Mar 15 12:35:18 2009 From: steve at traylen.net (Steve Traylen) Date: Sun, 15 Mar 2009 13:35:18 +0100 Subject: how to build srpms on koji? In-Reply-To: References: Message-ID: On Sun, Mar 15, 2009 at 10:55 AM, ??? wrote: > Hi, > After long time fighting with koji configuration, I think the service is now > running successfully. I added some srpms to it and saw its information on > kojiweb. But it seems I can not build the srpms by koji (when I submit a > build task to koji, it will "open" for a while, then it would finally come > to be failed). I doubted if I have missed some configurations which > connecting koji and mock. Does the build get as far as kojid. Is there anything in /var/log/kojid.log ? This can tell you the mock problem and then where to look for that. Steve > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > -- Steve Traylen From steve at traylen.net Sun Mar 15 15:39:04 2009 From: steve at traylen.net (Steve Traylen) Date: Sun, 15 Mar 2009 16:39:04 +0100 Subject: mergerepo fails with PCDATA invalid Char value 8 In-Reply-To: References: Message-ID: On Sun, Mar 15, 2009 at 12:45 PM, Steve Traylen wrote: > Hi, > ?Got koji basically working for me over the last couple of weeks. Was > very keen to > ?try its new external repository support. > > ?Starting with a fresh instance I made a tag (dist-slc5) ?containing two repos. > > ? koji add-external-repo -t dist-slc5 -p 10 "slc5-64-base" > http://linuxsoft.cern.ch/cern/slc5X/x86_64/yum/os > ? koji add-external-repo -t dist-slc5 -p 10 "slc5-32-base" > http://linuxsoft.cern.ch/cern/slc5X/i386/yum/os > > ?and then tried to make a koji repo from that. > > ? koji regen-repo dist-slc5 > > ? This called > > ? /usr/libexec/kojid/mergerepos -a i386 -b > /mnt/koji/repos/dist-slc5-build/189/i386/blocklist -o > /tmp/koji/tasks/556/556/repo \ > ? ? ? ? ? -g /mnt/koji/repos/dist-slc5-build/189/groups/comps.xml -r > http://linuxsoft.cern.ch/cern/slc5X/x86_64/yum/os/ \ > ? ? ? ? ? -r http://linuxsoft.cern.ch/cern/slc5X/i386/yum/os/ > > ?resulting in as below. Any ideas ? To hopefully answer my own question. Is this because these slc yum repositories do not contain the sqlite files thats that mergerepo makes use of. Looking at CentOS and ScientificLinux neither of these look to make use of the '-d' option to createrepo to generate the sqlite files. Is there a way around this or we have to ask CentOS to generate the sql files? Of course maybe it is something else entirely? Steve > > ? Steve > > > > process:19630): GLib-WARNING **: GError set over the top of a previous > GError or uninitialized memory. > This indicates a bug in someone's code. You must ensure an error is > NULL before it's set. > The overwriting error message was: Parsing other.xml error: PCDATA > invalid Char value 8 > > Traceback (most recent call last): > ?File "/usr/libexec/kojid/mergerepos", line 241, in > ? ?main(sys.argv[1:]) > ?File "/usr/libexec/kojid/mergerepos", line 236, in main > ? ?merge.write_metadata() > ?File "/usr/libexec/kojid/mergerepos", line 216, in write_metadata > ? ?mdgen.doPkgMetadata() > ?File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line > 332, in doPkgMetadata > ? ?self.writeMetadataDocs(packages) > ?File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line > 475, in writeMetadataDocs > ? ?clog_limit=self.conf.changelog_limit)) > ?File "/usr/lib/python2.5/site-packages/yum/packages.py", line 959, > in xml_dump_other_metadata > ? ?msg += "%s\n\n" % > misc.to_unicode(self._dump_changelog(clog_limit)) > ?File "/usr/lib/python2.5/site-packages/yum/packages.py", line 927, > in _dump_changelog > ? ?if not self.changelog: > ?File "/usr/lib/python2.5/site-packages/yum/packages.py", line 423, in > ? ?changelog = property(fget=lambda self: self.returnChangelog()) > ?File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 225, > in returnChangelog > ? ?self._loadChangelog() > ?File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 202, > in _loadChangelog > ? ?self.sack.populate(self.repo, mdtype='otherdata') > ?File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 184, in populate > ? ?dobj = repo_cache_function(xml, csum) > ?File "/usr/lib/python2.5/site-packages/sqlitecachec.py", line 60, in > getOtherdata > ? ?self.repoid)) > TypeError: Parsing other.xml error: PCDATA invalid Char value 8 > > > ? Steve > > > > > -- > Steve Traylen > -- Steve Traylen From mikeb at redhat.com Sun Mar 15 17:39:28 2009 From: mikeb at redhat.com (Mike Bonnet) Date: Sun, 15 Mar 2009 13:39:28 -0400 Subject: mergerepo fails with PCDATA invalid Char value 8 In-Reply-To: References: Message-ID: <49BD3D50.9090205@redhat.com> Steve Traylen wrote: > On Sun, Mar 15, 2009 at 12:45 PM, Steve Traylen wrote: >> Hi, >> Got koji basically working for me over the last couple of weeks. Was >> very keen to >> try its new external repository support. >> >> Starting with a fresh instance I made a tag (dist-slc5) containing two repos. >> >> koji add-external-repo -t dist-slc5 -p 10 "slc5-64-base" >> http://linuxsoft.cern.ch/cern/slc5X/x86_64/yum/os >> koji add-external-repo -t dist-slc5 -p 10 "slc5-32-base" >> http://linuxsoft.cern.ch/cern/slc5X/i386/yum/os >> >> and then tried to make a koji repo from that. >> >> koji regen-repo dist-slc5 >> >> This called >> >> /usr/libexec/kojid/mergerepos -a i386 -b >> /mnt/koji/repos/dist-slc5-build/189/i386/blocklist -o >> /tmp/koji/tasks/556/556/repo \ >> -g /mnt/koji/repos/dist-slc5-build/189/groups/comps.xml -r >> http://linuxsoft.cern.ch/cern/slc5X/x86_64/yum/os/ \ >> -r http://linuxsoft.cern.ch/cern/slc5X/i386/yum/os/ >> >> resulting in as below. Any ideas ? > > To hopefully answer my own question. Is this because these slc yum > repositories do not contain the sqlite files thats that mergerepo makes > use of. > Looking at CentOS and ScientificLinux neither of these look to make > use of the '-d' option to createrepo to generate the sqlite files. > Is there a way around this or we have to ask CentOS to generate > the sql files? The error occurs when parsing other.xml. I would check your external repos to see if other.xml passes XML validation successfully. > Of course maybe it is something else entirely? > Steve > > >> Steve >> >> >> >> process:19630): GLib-WARNING **: GError set over the top of a previous >> GError or uninitialized memory. >> This indicates a bug in someone's code. You must ensure an error is >> NULL before it's set. >> The overwriting error message was: Parsing other.xml error: PCDATA >> invalid Char value 8 >> >> Traceback (most recent call last): >> File "/usr/libexec/kojid/mergerepos", line 241, in >> main(sys.argv[1:]) >> File "/usr/libexec/kojid/mergerepos", line 236, in main >> merge.write_metadata() >> File "/usr/libexec/kojid/mergerepos", line 216, in write_metadata >> mdgen.doPkgMetadata() >> File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line >> 332, in doPkgMetadata >> self.writeMetadataDocs(packages) >> File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line >> 475, in writeMetadataDocs >> clog_limit=self.conf.changelog_limit)) >> File "/usr/lib/python2.5/site-packages/yum/packages.py", line 959, >> in xml_dump_other_metadata >> msg += "%s\n\n" % >> misc.to_unicode(self._dump_changelog(clog_limit)) >> File "/usr/lib/python2.5/site-packages/yum/packages.py", line 927, >> in _dump_changelog >> if not self.changelog: >> File "/usr/lib/python2.5/site-packages/yum/packages.py", line 423, in >> changelog = property(fget=lambda self: self.returnChangelog()) >> File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 225, >> in returnChangelog >> self._loadChangelog() >> File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 202, >> in _loadChangelog >> self.sack.populate(self.repo, mdtype='otherdata') >> File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 184, in populate >> dobj = repo_cache_function(xml, csum) >> File "/usr/lib/python2.5/site-packages/sqlitecachec.py", line 60, in >> getOtherdata >> self.repoid)) >> TypeError: Parsing other.xml error: PCDATA invalid Char value 8 >> >> >> Steve >> >> >> >> >> -- >> Steve Traylen >> > > > From wacker at octothorp.org Mon Mar 16 00:09:02 2009 From: wacker at octothorp.org (William F. Acker WB2FLW +1 303 722 7209) Date: Sun, 15 Mar 2009 18:09:02 -0600 (MDT) Subject: Error from repoview when composing with pungi. In-Reply-To: <1235001752.16686.160.camel@rosebud> References: <1234973794.16686.111.camel@rosebud> <1234993395.16686.141.camel@rosebud> <1235001752.16686.160.camel@rosebud> Message-ID: On Wed, 18 Feb 2009, seth vidal wrote: > On Wed, 2009-02-18 at 16:43 -0500, seth vidal wrote: >> On Wed, 2009-02-18 at 14:35 -0700, William F. Acker WB2FLW +1 303 722 >> 7209 wrote: >> >>> I back leveled sqlite on the build machine which didn't help. I know >>> that's not conclusive since some packages such as Anaconda are downloaded >>> from the repo and never cached. So, before putting the old sqlite into >>> the repo, I checked to see the when I was last successful VS when I >>> installed sqlite. It turns out that both yum and sqlite were installed on >>> 2/5, and my last successful spin was on 2/8. I don't see any packages >>> installed since them that are obviously connected to this problem. >>> >> >> I'm not sure if this is sqlite anymore - I've been mucking with it >> today. Oddly on rawhide here I can't make it happen. >> >> > > ah ha! My sample size was too small. I found out what was causing the > problem > > somehow we had two packages VLGothic-fonts and vlgothic-fonts - repoview > case normalizes for the .html files it makes - hence this problem. > Fedora was not supposed to have those two pkgs - it was an oversight and > that has been fixed. I'll also change repoview to not case normalize the > filenames. Hi again, I haven't seen new fonts or a new version of repoview. Openoffice-langpack-jp requires either the old or new fonts, so I don't see how I could exclude them. How should I proceed? TIA -- Bill in Denver From chenbaozi at gmail.com Mon Mar 16 01:36:30 2009 From: chenbaozi at gmail.com (=?UTF-8?B?6ZmI6bKN5a2c?=) Date: Mon, 16 Mar 2009 09:36:30 +0800 Subject: how to build srpms on koji? In-Reply-To: References: Message-ID: I checked the /var/log/kojid.log. it is said: 2009-03-14 17:03:14,371 [WARNING] koji.build.TaskManager: TRACEBACK: Traceback (most recent call last): File "/usr/sbin/kojid", line 1275, in runTask response = (handler.run(),) File "/usr/sbin/kojid", line 1351, in run return self.handler(*self.params,**self.opts) File "/usr/sbin/kojid", line 2560, in handler for f in os.listdir(self.datadir): OSError: [Errno 2] No such file or directory: '/tmp/koji/tasks/230/230/repo/repoda 2009/3/15 Steve Traylen > On Sun, Mar 15, 2009 at 10:55 AM, ??? wrote: > > Hi, > > After long time fighting with koji configuration, I think the service is > now > > running successfully. I added some srpms to it and saw its information on > > kojiweb. But it seems I can not build the srpms by koji (when I submit a > > build task to koji, it will "open" for a while, then it would finally > come > > to be failed). I doubted if I have missed some configurations which > > connecting koji and mock. > > Does the build get as far as kojid. Is there anything in > /var/log/kojid.log ? This can tell > you the mock problem and then where to look for that. > Steve > > > > > -- > > Fedora-buildsys-list mailing list > > Fedora-buildsys-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > > > > > -- > Steve Traylen > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikeb at redhat.com Mon Mar 16 01:56:08 2009 From: mikeb at redhat.com (Mike Bonnet) Date: Sun, 15 Mar 2009 21:56:08 -0400 Subject: how to build srpms on koji? In-Reply-To: References: Message-ID: <49BDB1B8.4030702@redhat.com> ??? wrote: > I checked the /var/log/kojid.log. it is said: > > 2009-03-14 17:03:14,371 [WARNING] koji.build.TaskManager: TRACEBACK: > Traceback (most recent call last): > File "/usr/sbin/kojid", line 1275, in runTask > response = (handler.run(),) > File "/usr/sbin/kojid", line 1351, in run > return self.handler(*self.params,**self.opts) > File "/usr/sbin/kojid", line 2560, in handler > for f in os.listdir(self.datadir): > OSError: [Errno 2] No such file or directory: > '/tmp/koji/tasks/230/230/repo/repoda > 2009/3/15 Steve Traylen If your build tag has no builds associated or inherited, and no external repos configured, then no repodata will be created and the task will fail this way when it tries to upload the repodata. Tag a package into the build tag, or enable an external repo. >> On Sun, Mar 15, 2009 at 10:55 AM, ??? wrote: >>> Hi, >>> After long time fighting with koji configuration, I think the service is >> now >>> running successfully. I added some srpms to it and saw its information on >>> kojiweb. But it seems I can not build the srpms by koji (when I submit a >>> build task to koji, it will "open" for a while, then it would finally >> come >>> to be failed). I doubted if I have missed some configurations which >>> connecting koji and mock. >> Does the build get as far as kojid. Is there anything in >> /var/log/kojid.log ? This can tell >> you the mock problem and then where to look for that. >> Steve >> >>> -- >>> Fedora-buildsys-list mailing list >>> Fedora-buildsys-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-buildsys-list >>> >> >> >> -- >> Steve Traylen >> >> -- >> Fedora-buildsys-list mailing list >> Fedora-buildsys-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-buildsys-list >> > > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From jiteshs at marvell.com Mon Mar 16 07:28:50 2009 From: jiteshs at marvell.com (Jitesh Shah) Date: Mon, 16 Mar 2009 12:58:50 +0530 Subject: buildSRPMfromSCM issue Message-ID: <1237188530.11828.11.camel@localhost.localdomain> Hi all, I've been trying out some stuff on my own local koji instance. Recently, I added a new builder and all the builds using SCMs started to fail (although, scratch builds on SRPMs work just fine). buildSRPMfromSCM fails. The checkouts go through fine and "make sources" also works. Following is the tail of the root.log (after "make sources") DEBUG util.py:251: 3 2266k 73 1670k 0 0 239k 0 0:00:09 0:00:06 0:00:03 310k 87 2266k 87 1976k 0 0 247k 0 0:00:09 0:00:07 0:00:02 310k 100 2266k 100 2266k 0 DEBUG util.py:251: DEBUG util.py:251: 0 DEBUG util.py:251: DEBUG util.py:251: DEBUG util.py:251: DEBUG util.py:251: 253k 0 0:00:08 0:00:08 --:--:-- 307k DEBUG util.py:251: -rw-rw-r-- 1 mockbuild mockbuild 2321402 Jun 18 2007 libidn-0.6.14.tar.gz DEBUG util.py:312: Child returncode was: 0 DEBUG backend.py:484: umount -n /var/lib/mock/dist-f10-build-139-697/root/proc DEBUG util.py:273: Executing command: umount -n /var/lib/mock/dist-f10-build-139-697/root/proc DEBUG util.py:312: Child returncode was: 0 DEBUG backend.py:484: umount -n /var/lib/mock/dist-f10-build-139-697/root/sys DEBUG util.py:273: Executing command: umount -n /var/lib/mock/dist-f10-build-139-697/root/sys DEBUG util.py:312: Child returncode was: 0 DEBUG util.py:99: kill orphans The task exits with "FAILED: BuildError: error building srpm, mock exited with status 2; see root.log for more information" But, there is nothing suspicious in root.log (yum succeeds, so does checkout and "make sources" and there are no errors after that too). state.log and kojid.log also give out nothing. I have enabled full debugging from kojihub.conf. How do I go about solving this issue? From where can I glean more information about the problem? What does "mock exited with status 2" mean? and more importantly, why does mock give up abruptly? Jitesh From steve at traylen.net Mon Mar 16 09:03:10 2009 From: steve at traylen.net (Steve Traylen) Date: Mon, 16 Mar 2009 10:03:10 +0100 Subject: mergerepo fails with PCDATA invalid Char value 8 In-Reply-To: <49BD3D50.9090205@redhat.com> References: <49BD3D50.9090205@redhat.com> Message-ID: On Sun, Mar 15, 2009 at 6:39 PM, Mike Bonnet wrote: > Steve Traylen wrote: >> >> On Sun, Mar 15, 2009 at 12:45 PM, Steve Traylen wrote: >>> >>> Hi, >>> ?Got koji basically working for me over the last couple of weeks. Was >>> very keen to >>> ?try its new external repository support. >>> >>> ?Starting with a fresh instance I made a tag (dist-slc5) ?containing two >>> repos. >>> >>> ?koji add-external-repo -t dist-slc5 -p 10 "slc5-64-base" >>> http://linuxsoft.cern.ch/cern/slc5X/x86_64/yum/os >>> ?koji add-external-repo -t dist-slc5 -p 10 "slc5-32-base" >>> http://linuxsoft.cern.ch/cern/slc5X/i386/yum/os >>> >>> ?and then tried to make a koji repo from that. >>> >>> ?koji regen-repo dist-slc5 >>> >>> ?This called >>> >>> ?/usr/libexec/kojid/mergerepos -a i386 -b >>> /mnt/koji/repos/dist-slc5-build/189/i386/blocklist -o >>> /tmp/koji/tasks/556/556/repo \ >>> ? ? ? ? ?-g /mnt/koji/repos/dist-slc5-build/189/groups/comps.xml -r >>> http://linuxsoft.cern.ch/cern/slc5X/x86_64/yum/os/ \ >>> ? ? ? ? ?-r http://linuxsoft.cern.ch/cern/slc5X/i386/yum/os/ >>> >>> ?resulting in as below. Any ideas ? >> >> To hopefully answer my own question. Is this because these slc yum >> repositories do not contain the sqlite files thats that mergerepo makes >> use of. >> Looking at CentOS and ScientificLinux neither of these look to make >> use of the '-d' option to createrepo to generate the sqlite files. >> Is there a way around this or we have to ask CentOS to generate >> the sql files? > > The error occurs when parsing other.xml. ?I would check your external repos > to see if other.xml passes XML validation successfully. Hi Mike, That's exactly the problem. Thanks. It fails later now but I'll look into it first. Steve > >> Of course maybe it is something else entirely? >> Steve >> >> >>> ?Steve >>> >>> >>> >>> process:19630): GLib-WARNING **: GError set over the top of a previous >>> GError or uninitialized memory. >>> This indicates a bug in someone's code. You must ensure an error is >>> NULL before it's set. >>> The overwriting error message was: Parsing other.xml error: PCDATA >>> invalid Char value 8 >>> >>> Traceback (most recent call last): >>> ?File "/usr/libexec/kojid/mergerepos", line 241, in >>> ? main(sys.argv[1:]) >>> ?File "/usr/libexec/kojid/mergerepos", line 236, in main >>> ? merge.write_metadata() >>> ?File "/usr/libexec/kojid/mergerepos", line 216, in write_metadata >>> ? mdgen.doPkgMetadata() >>> ?File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line >>> 332, in doPkgMetadata >>> ? self.writeMetadataDocs(packages) >>> ?File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line >>> 475, in writeMetadataDocs >>> ? clog_limit=self.conf.changelog_limit)) >>> ?File "/usr/lib/python2.5/site-packages/yum/packages.py", line 959, >>> in xml_dump_other_metadata >>> ? msg += "%s\n\n" % >>> misc.to_unicode(self._dump_changelog(clog_limit)) >>> ?File "/usr/lib/python2.5/site-packages/yum/packages.py", line 927, >>> in _dump_changelog >>> ? if not self.changelog: >>> ?File "/usr/lib/python2.5/site-packages/yum/packages.py", line 423, in >>> >>> ? changelog = property(fget=lambda self: self.returnChangelog()) >>> ?File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 225, >>> in returnChangelog >>> ? self._loadChangelog() >>> ?File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 202, >>> in _loadChangelog >>> ? self.sack.populate(self.repo, mdtype='otherdata') >>> ?File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 184, in >>> populate >>> ? dobj = repo_cache_function(xml, csum) >>> ?File "/usr/lib/python2.5/site-packages/sqlitecachec.py", line 60, in >>> getOtherdata >>> ? self.repoid)) >>> TypeError: Parsing other.xml error: PCDATA invalid Char value 8 >>> >>> >>> ?Steve >>> >>> >>> >>> >>> -- >>> Steve Traylen >>> >> >> >> > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > -- Steve Traylen From steve at traylen.net Mon Mar 16 12:07:55 2009 From: steve at traylen.net (Steve Traylen) Date: Mon, 16 Mar 2009 13:07:55 +0100 Subject: unicode error with mergerepos against CentOS 5. Message-ID: Hi, $ rpm -qf /usr/libexec/kojid/mergerepos koji-builder-1.3.1-1.fc10.noarch Running agaist Fedora repositories all looks well but against CentOS. /usr/libexec/kojid/mergerepos -a x86_64 \ -o repo \ -r http://swissmirror.silyus.net/centos/5.2/os/i386/ Adding repo: http://swissmirror.silyus.net/centos/5.2/os/i386/ 1/400 - Deployment_Guide-or-IN-5.2-9.el5.centos.noarch 2/400 - 1:kde-i18n-Icelandic-3.5.4-1.noarch .... .... 328/400 - system-config-users-1.2.51-4.el5.noarch 329/400 - yum-priorities-1.1.10-9.el5.centos.noarch Traceback (most recent call last): File "/usr/libexec/kojid/mergerepos", line 241, in main(sys.argv[1:]) File "/usr/libexec/kojid/mergerepos", line 236, in main merge.write_metadata() File "/usr/libexec/kojid/mergerepos", line 216, in write_metadata mdgen.doPkgMetadata() File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line 332, in doPkgMetadata self.writeMetadataDocs(packages) File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line 472, in writeMetadataDocs self.primaryfile.write(po.xml_dump_primary_metadata()) File "/usr/lib/python2.5/site-packages/yum/packages.py", line 943, in xml_dump_primary_metadata msg += misc.to_unicode(self._dump_format_items()) File "/usr/lib/python2.5/site-packages/yum/packages.py", line 809, in _dump_format_items msg += self._dump_pco('provides') UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 38: ordinal not in range(128) Tried with a few other repos as well, e.g the i386 one , the two merged , ... it fails the same though apparently at different packages. -- Steve Traylen From skvidal at fedoraproject.org Mon Mar 16 12:29:50 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 16 Mar 2009 08:29:50 -0400 (EDT) Subject: unicode error with mergerepos against CentOS 5. In-Reply-To: References: Message-ID: On Mon, 16 Mar 2009, Steve Traylen wrote: > Hi, > > $ rpm -qf /usr/libexec/kojid/mergerepos > koji-builder-1.3.1-1.fc10.noarch > > Running agaist Fedora repositories all looks well but against CentOS. > > /usr/libexec/kojid/mergerepos -a x86_64 \ > -o repo \ > -r http://swissmirror.silyus.net/centos/5.2/os/i386/ > > Adding repo: http://swissmirror.silyus.net/centos/5.2/os/i386/ > 1/400 - Deployment_Guide-or-IN-5.2-9.el5.centos.noarch > 2/400 - 1:kde-i18n-Icelandic-3.5.4-1.noarch > .... > .... > 328/400 - system-config-users-1.2.51-4.el5.noarch > 329/400 - yum-priorities-1.1.10-9.el5.centos.noarch > Traceback (most recent call last): > File "/usr/libexec/kojid/mergerepos", line 241, in > main(sys.argv[1:]) > File "/usr/libexec/kojid/mergerepos", line 236, in main > merge.write_metadata() > File "/usr/libexec/kojid/mergerepos", line 216, in write_metadata > mdgen.doPkgMetadata() > File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line > 332, in doPkgMetadata > self.writeMetadataDocs(packages) > File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line > 472, in writeMetadataDocs > self.primaryfile.write(po.xml_dump_primary_metadata()) > File "/usr/lib/python2.5/site-packages/yum/packages.py", line 943, > in xml_dump_primary_metadata > msg += misc.to_unicode(self._dump_format_items()) > File "/usr/lib/python2.5/site-packages/yum/packages.py", line 809, > in _dump_format_items > msg += self._dump_pco('provides') > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position > 38: ordinal not in range(128) > > Tried with a few other repos as well, e.g the i386 one , the two > merged , ... it fails the same > though apparently at different packages. > the metadata you're pulling in was written with a much older createrepo which was less picky about some of the data it wrote back out. So you end up with some pkgs with dodgy data in the changelogs. -sv From chenbaozi at gmail.com Mon Mar 16 13:01:57 2009 From: chenbaozi at gmail.com (=?UTF-8?B?6ZmI6bKN5a2c?=) Date: Mon, 16 Mar 2009 21:01:57 +0800 Subject: how to build srpms on koji? In-Reply-To: <49BDB1B8.4030702@redhat.com> References: <49BDB1B8.4030702@redhat.com> Message-ID: I am trying to running the local koji instance. Do I have to make some extra configurations beside what the wiki have mentioned? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikeb at redhat.com Mon Mar 16 14:27:47 2009 From: mikeb at redhat.com (Mike Bonnet) Date: Mon, 16 Mar 2009 10:27:47 -0400 Subject: buildSRPMfromSCM issue In-Reply-To: <1237188530.11828.11.camel@localhost.localdomain> References: <1237188530.11828.11.camel@localhost.localdomain> Message-ID: <49BE61E3.3000305@redhat.com> Jitesh Shah wrote: > Hi all, > I've been trying out some stuff on my own local koji instance. Recently, > I added a new builder and all the builds using SCMs started to fail > (although, scratch builds on SRPMs work just fine). > buildSRPMfromSCM fails. > > The checkouts go through fine and "make sources" also works. Following > is the tail of the root.log (after "make sources") > > DEBUG util.py:251: 3 2266k 73 1670k 0 0 239k 0 0:00:09 > 0:00:06 0:00:03 310k > 87 2266k 87 1976k 0 0 247k 0 0:00:09 0:00:07 0:00:02 > 310k > 100 2266k 100 2266k 0 > DEBUG util.py:251: > DEBUG util.py:251: 0 > DEBUG util.py:251: > DEBUG util.py:251: > DEBUG util.py:251: > DEBUG util.py:251: 253k 0 0:00:08 0:00:08 --:--:-- 307k > DEBUG util.py:251: -rw-rw-r-- 1 mockbuild mockbuild 2321402 Jun 18 > 2007 libidn-0.6.14.tar.gz > DEBUG util.py:312: Child returncode was: 0 > DEBUG backend.py:484: umount > -n /var/lib/mock/dist-f10-build-139-697/root/proc > DEBUG util.py:273: Executing command: umount > -n /var/lib/mock/dist-f10-build-139-697/root/proc > DEBUG util.py:312: Child returncode was: 0 > DEBUG backend.py:484: umount > -n /var/lib/mock/dist-f10-build-139-697/root/sys > DEBUG util.py:273: Executing command: umount > -n /var/lib/mock/dist-f10-build-139-697/root/sys > DEBUG util.py:312: Child returncode was: 0 > DEBUG util.py:99: kill orphans > > > > The task exits with "FAILED: BuildError: error building srpm, mock > exited with status 2; see root.log for more information" > But, there is nothing suspicious in root.log (yum succeeds, so does > checkout and "make sources" and there are no errors after that too). > state.log and kojid.log also give out nothing. I have enabled full > debugging from kojihub.conf. That error means "mock --buildsrpm" failed. I'm not sure what status 2 is, it probably means a failure in rpmbuild in the chroot. There should be more information in root.log, I'm not sure why there isn't. Does building the srpm by hand work? From steve at traylen.net Tue Mar 17 15:59:54 2009 From: steve at traylen.net (Steve Traylen) Date: Tue, 17 Mar 2009 16:59:54 +0100 Subject: mergerepos of f10 x86_64 release and updates does not contain perl or some other packages? Message-ID: Hi, Merging works fine for i386 f10 repositories but for x86_64 the following happens. The merged repository of f10's "Everything" and "updates" is created and then using this new repo mock tries to create and installroot. The problem is that this new repository is unable to provide some items, perl, /bin/bash and so the install root fails. Here are the details. The "blocklist" file following here is empty. $ /usr/libexec/kojid/mergerepos -a x86_64 \ -b /mnt/koji/repos/dist-f10-build/671/x86_64/blocklist \ -o /tmp/koji/tasks/2021/2021/repo \ -g /mnt/koji/repos/dist-f10-build/671/groups/comps.xml \ -r http://mirror.switch.ch/ftp/mirror/fedora/linux/updates/10/x86_64/ \ -r http://mirror.switch.ch/ftp/mirror/fedora/linux/releases/10/Everything/x86_64/os/ Adding repo: http://mirror.switch.ch/ftp/mirror/fedora/linux/updates/10/x86_64/ Adding repo: http://mirror.switch.ch/ftp/mirror/fedora/linux/releases/10/Everything/x86_64/os/ 1/12364 - openswan-doc-2.6.19-1.fc10.x86_64 2/12364 - ssm-0.1-12.fc10.x86_64 ... ... 1112/12364 - 4:perl-5.10.0-56.fc10.x86_64 ... ... 12363/12364 - libextractor-plugins-exiv2-0.5.20b-2.fc10.x86_64 12364/12364 - lwp-devel-2.4-1.fc10.x86_64 Saving Primary metadata Saving file lists metadata Saving other metadata Generating sqlite DBs Starting other db creation: Tue Mar 17 14:49:44 2009 Ending other db creation: Tue Mar 17 14:50:50 2009 Starting filelists db creation: Tue Mar 17 14:51:03 2009 Ending filelists db creation: Tue Mar 17 14:55:37 2009 Starting primary db creation: Tue Mar 17 14:55:40 2009 Ending primary db creation: Tue Mar 17 14:58:28 2009 Sqlite DBs complete The following is then tried from within mock. The chroot's yum.conf is definitely referencing the repository I just created (I've checked carefully and have recreated the repo a few times just to check this is consistent. ) /usr/bin/yum --installroot /var/lib/mock/dist-f10-build-13-671/root/ \ groupinstall build this results in EBUG util.py:256: redhat-rpm-config-9.0.3-3.fc10.noarch from build has depsolving problems DEBUG util.py:256: --> Missing Dependency: /usr/bin/perl is needed by package redhat-rpm-config-9.0.3-3.fc10.noarch (build) DEBUG util.py:256: redhat-rpm-config-9.0.3-3.fc10.noarch from build has depsolving problems DEBUG util.py:256: --> Missing Dependency: perl(Getopt::Long) is needed by package redhat-rpm-config-9.0.3-3.fc10.noarch (build) DEBUG util.py:256: redhat-rpm-config-9.0.3-3.fc10.noarch from build has depsolving problems DEBUG util.py:256: --> Missing Dependency: /bin/sh is needed by package redhat-rpm-config-9.0.3-3.fc10.noarch (build) DEBUG util.py:256: redhat-rpm-config-9.0.3-3.fc10.noarch from build has depsolving problems DEBUG util.py:256: --> Missing Dependency: mktemp is needed by package redhat-rpm-config-9.0.3-3.fc10.noarch (build) DEBUG util.py:256: fedora-release-notes-10.0.0-1.noarch from build has depsolving problems DEBUG util.py:256: --> Missing Dependency: /bin/sh is needed by package fedora-release-notes-10.0.0-1.noarch (build) DEBUG util.py:256: redhat-rpm-config-9.0.3-3.fc10.noarch from build has depsolving problems DEBUG util.py:256: --> Missing Dependency: /bin/bash is needed by package redhat-rpm-config-9.0.3-3.fc10.noarch (build) DEBUG util.py:256: Error: Missing Dependency: /bin/bash is needed by package redhat-rpm-config-9.0.3-3.fc10.noarch (build) DEBUG util.py:256: Error: Missing Dependency: mktemp is needed by package redhat-rpm-config-9.0.3-3.fc10.noarch (build) DEBUG util.py:256: Error: Missing Dependency: /bin/sh is needed by package fedora-release-notes-10.0.0-1.noarch (build) DEBUG util.py:256: Error: Missing Dependency: /usr/bin/perl is needed by package redhat-rpm-config-9.0.3-3.fc10.noarch (build) DEBUG util.py:256: Error: Missing Dependency: /bin/sh is needed by package redhat-rpm-config-9.0.3-3.fc10.noarch (build) DEBUG util.py:256: Error: Missing Dependency: perl(Getopt::Long) is needed by package redhat-rpm-config-9.0.3-3.fc10.noarch (build) And indeed. /usr/bin/yum --installroot /var/lib/mock/dist-f10-build-13-671/root list perl Error: No matching Packages to list There are lots of packages in this repository, but no perl it seems. /usr/bin/yum --installroot /var/lib/mock/dist-f10-build-13-671/root list | wc -l shows 3483 packages. Note the main box I am working on is 32 bit F10 box which may be relevant and the reason why only subsequently the i386 build works? Steve -- Steve Traylen From mikeb at redhat.com Tue Mar 17 16:08:43 2009 From: mikeb at redhat.com (Mike Bonnet) Date: Tue, 17 Mar 2009 12:08:43 -0400 Subject: mergerepos of f10 x86_64 release and updates does not contain perl or some other packages? In-Reply-To: References: Message-ID: <49BFCB0B.1090307@redhat.com> Steve Traylen wrote: > Hi, > > Merging works fine for i386 f10 repositories but for x86_64 the > following happens. > > The merged repository of f10's "Everything" and "updates" is created > and then using > this new repo mock tries to create and installroot. > > The problem is that this new repository is unable to provide > some items, perl, /bin/bash and so the install root fails. > > Here are the details. > > The "blocklist" file following here is empty. > > $ /usr/libexec/kojid/mergerepos -a x86_64 \ > -b /mnt/koji/repos/dist-f10-build/671/x86_64/blocklist \ > -o /tmp/koji/tasks/2021/2021/repo \ > -g /mnt/koji/repos/dist-f10-build/671/groups/comps.xml \ > -r http://mirror.switch.ch/ftp/mirror/fedora/linux/updates/10/x86_64/ \ > -r http://mirror.switch.ch/ftp/mirror/fedora/linux/releases/10/Everything/x86_64/os/ > > Adding repo: http://mirror.switch.ch/ftp/mirror/fedora/linux/updates/10/x86_64/ > Adding repo: http://mirror.switch.ch/ftp/mirror/fedora/linux/releases/10/Everything/x86_64/os/ > 1/12364 - openswan-doc-2.6.19-1.fc10.x86_64 > 2/12364 - ssm-0.1-12.fc10.x86_64 > ... > ... > 1112/12364 - 4:perl-5.10.0-56.fc10.x86_64 > ... > ... > 12363/12364 - libextractor-plugins-exiv2-0.5.20b-2.fc10.x86_64 > 12364/12364 - lwp-devel-2.4-1.fc10.x86_64 > > Saving Primary metadata > Saving file lists metadata > Saving other metadata > Generating sqlite DBs > Starting other db creation: Tue Mar 17 14:49:44 2009 > Ending other db creation: Tue Mar 17 14:50:50 2009 > Starting filelists db creation: Tue Mar 17 14:51:03 2009 > Ending filelists db creation: Tue Mar 17 14:55:37 2009 > Starting primary db creation: Tue Mar 17 14:55:40 2009 > Ending primary db creation: Tue Mar 17 14:58:28 2009 > Sqlite DBs complete > > The following is then tried from within mock. The chroot's yum.conf is > definitely > referencing the repository I just created (I've checked carefully and have > recreated the repo a few times just to check this is consistent. ) > > /usr/bin/yum --installroot /var/lib/mock/dist-f10-build-13-671/root/ \ > groupinstall build > > this results in > > EBUG util.py:256: redhat-rpm-config-9.0.3-3.fc10.noarch from build > has depsolving problems > DEBUG util.py:256: --> Missing Dependency: /usr/bin/perl is needed > by package redhat-rpm-config-9.0.3-3.fc10.noarch (build) > DEBUG util.py:256: redhat-rpm-config-9.0.3-3.fc10.noarch from build > has depsolving problems > DEBUG util.py:256: --> Missing Dependency: perl(Getopt::Long) is > needed by package redhat-rpm-config-9.0.3-3.fc10.noarch (build) > DEBUG util.py:256: redhat-rpm-config-9.0.3-3.fc10.noarch from build > has depsolving problems > DEBUG util.py:256: --> Missing Dependency: /bin/sh is needed by > package redhat-rpm-config-9.0.3-3.fc10.noarch (build) > DEBUG util.py:256: redhat-rpm-config-9.0.3-3.fc10.noarch from build > has depsolving problems > DEBUG util.py:256: --> Missing Dependency: mktemp is needed by > package redhat-rpm-config-9.0.3-3.fc10.noarch (build) > DEBUG util.py:256: fedora-release-notes-10.0.0-1.noarch from build > has depsolving problems > DEBUG util.py:256: --> Missing Dependency: /bin/sh is needed by > package fedora-release-notes-10.0.0-1.noarch (build) > DEBUG util.py:256: redhat-rpm-config-9.0.3-3.fc10.noarch from build > has depsolving problems > DEBUG util.py:256: --> Missing Dependency: /bin/bash is needed by > package redhat-rpm-config-9.0.3-3.fc10.noarch (build) > DEBUG util.py:256: Error: Missing Dependency: /bin/bash is needed by > package redhat-rpm-config-9.0.3-3.fc10.noarch (build) > DEBUG util.py:256: Error: Missing Dependency: mktemp is needed by > package redhat-rpm-config-9.0.3-3.fc10.noarch (build) > DEBUG util.py:256: Error: Missing Dependency: /bin/sh is needed by > package fedora-release-notes-10.0.0-1.noarch (build) > DEBUG util.py:256: Error: Missing Dependency: /usr/bin/perl is needed > by package redhat-rpm-config-9.0.3-3.fc10.noarch (build) > DEBUG util.py:256: Error: Missing Dependency: /bin/sh is needed by > package redhat-rpm-config-9.0.3-3.fc10.noarch (build) > DEBUG util.py:256: Error: Missing Dependency: perl(Getopt::Long) is > needed by package redhat-rpm-config-9.0.3-3.fc10.noarch (build) > > And indeed. > > /usr/bin/yum --installroot /var/lib/mock/dist-f10-build-13-671/root list perl > Error: No matching Packages to list > > There are lots of packages in this repository, but no perl it seems. > > /usr/bin/yum --installroot /var/lib/mock/dist-f10-build-13-671/root > list | wc -l > shows 3483 packages. > > Note the main box I am working on is 32 bit F10 box which may be relevant and > the reason why only subsequently the i386 build works? You can't use a x86_64 chroot on a i386 box, nothing in the chroot will run. I suspect rpm is preventing installation of x86_64 packages on a i386 host. From kanarip at kanarip.com Tue Mar 17 16:35:35 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 17 Mar 2009 17:35:35 +0100 Subject: mergerepos of f10 x86_64 release and updates does not contain perl or some other packages? In-Reply-To: <49BFCB0B.1090307@redhat.com> References: <49BFCB0B.1090307@redhat.com> Message-ID: <46283e1a518487ba21b8681305f76892@localhost> On Tue, 17 Mar 2009 12:08:43 -0400, Mike Bonnet wrote: > Steve Traylen wrote: >> Note the main box I am working on is 32 bit F10 box which may be relevant >> and >> the reason why only subsequently the i386 build works? > > You can't use a x86_64 chroot on a i386 box, nothing in the chroot will > run. I suspect rpm is preventing installation of x86_64 packages on a > i386 host. > I think it's YUM that does not include the x86_64 in the pkgSack (using yum.rpmUtils.arch.getArchList() over rpmUtils.arch.getBaseArch()). Kind regards, Jeroen van Meeuwen -kanarip From skvidal at fedoraproject.org Tue Mar 17 17:06:57 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 17 Mar 2009 13:06:57 -0400 (EDT) Subject: mergerepos of f10 x86_64 release and updates does not contain perl or some other packages? In-Reply-To: <46283e1a518487ba21b8681305f76892@localhost> References: <49BFCB0B.1090307@redhat.com> <46283e1a518487ba21b8681305f76892@localhost> Message-ID: On Tue, 17 Mar 2009, Jeroen van Meeuwen wrote: > > On Tue, 17 Mar 2009 12:08:43 -0400, Mike Bonnet wrote: >> Steve Traylen wrote: >>> Note the main box I am working on is 32 bit F10 box which may be > relevant >>> and >>> the reason why only subsequently the i386 build works? >> >> You can't use a x86_64 chroot on a i386 box, nothing in the chroot will >> run. I suspect rpm is preventing installation of x86_64 packages on a >> i386 host. >> > > I think it's YUM that does not include the x86_64 in the pkgSack (using > yum.rpmUtils.arch.getArchList() over rpmUtils.arch.getBaseArch()). > yep. Yum is saying "I'm on i386, I'm going to dump out all these arches which are not compatible at all" -sv From steve at traylen.net Wed Mar 18 13:15:50 2009 From: steve at traylen.net (Steve Traylen) Date: Wed, 18 Mar 2009 14:15:50 +0100 Subject: unicode error with mergerepos against CentOS 5. In-Reply-To: References: Message-ID: On Mon, Mar 16, 2009 at 1:29 PM, Seth Vidal wrote: > > > On Mon, 16 Mar 2009, Steve Traylen wrote: > >> Hi, >> >> $ rpm -qf /usr/libexec/kojid/mergerepos >> koji-builder-1.3.1-1.fc10.noarch >> >> Running agaist Fedora repositories all looks well but against CentOS. >> >> /usr/libexec/kojid/mergerepos -a x86_64 \ >> ?-o repo ?\ >> ?-r ?http://swissmirror.silyus.net/centos/5.2/os/i386/ >> >> Adding repo: http://swissmirror.silyus.net/centos/5.2/os/i386/ >> 1/400 - Deployment_Guide-or-IN-5.2-9.el5.centos.noarch >> 2/400 - 1:kde-i18n-Icelandic-3.5.4-1.noarch >> .... >> .... >> 328/400 - system-config-users-1.2.51-4.el5.noarch >> 329/400 - yum-priorities-1.1.10-9.el5.centos.noarch >> Traceback (most recent call last): >> File "/usr/libexec/kojid/mergerepos", line 241, in >> ?main(sys.argv[1:]) >> File "/usr/libexec/kojid/mergerepos", line 236, in main >> ?merge.write_metadata() >> File "/usr/libexec/kojid/mergerepos", line 216, in write_metadata >> ?mdgen.doPkgMetadata() >> File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line >> 332, in doPkgMetadata >> ?self.writeMetadataDocs(packages) >> File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line >> 472, in writeMetadataDocs >> ?self.primaryfile.write(po.xml_dump_primary_metadata()) >> File "/usr/lib/python2.5/site-packages/yum/packages.py", line 943, >> in xml_dump_primary_metadata >> ?msg += misc.to_unicode(self._dump_format_items()) >> File "/usr/lib/python2.5/site-packages/yum/packages.py", line 809, >> in _dump_format_items >> ?msg += self._dump_pco('provides') >> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position >> 38: ordinal not in range(128) >> >> Tried with a few other repos as well, e.g the i386 one , the two >> merged , ... it fails the same >> though apparently ?at different packages. >> > > the metadata you're pulling in was written with a much older createrepo > which was less picky about some of the data it wrote back out. So you end up > with some pkgs with dodgy data in the changelogs. Mirroring in CentOS5 and then recreating from scratch the repodirs with a Fedora 10 createrepo the the repository is created spitting out some warnings. 1556/2382 - CentOS/ghostscript-devel-8.15.2-9.1.el5_1.1.i386.rpm iso-8859-1 encoding on /usr/lib/aspell-0.60/?slenska.alias 1598/2382 - CentOS/avalon-logkit-javadoc-1.2-4jpp.3.i386.rpm iso-8859-1 encoding on Ville Skytt? - 1:0.2-1jpp and then the merge fails with. /usr/libexec/kojid/mergerepos -a i386 \ -o repo \ -r http://skojihub.cern.ch/mirror/centos/5/updates/i386 \ -r http://skojihub.cern.ch/mirror/centos/5/os/i386 Adding repo: http://skojihub.cern.ch/mirror/centos/5/updates/i386 Adding repo: http://skojihub.cern.ch/mirror/centos/5/os/i386 1/2607 - openssl-perl-0.9.8b-10.el5_2.1.i386 2/2607 - 1:cups-1.2.4-11.18.el5_2.3.i386 .... 1353/2607 - ImageMagick-c++-6.2.8.0-4.el5_1.1.i386 1354/2607 - mesa-libGL-6.5.1-7.5.el5.i386 Traceback (most recent call last): File "/usr/libexec/kojid/mergerepos", line 241, in main(sys.argv[1:]) File "/usr/libexec/kojid/mergerepos", line 236, in main merge.write_metadata() File "/usr/libexec/kojid/mergerepos", line 216, in write_metadata mdgen.doPkgMetadata() File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line 332, in doPkgMetadata self.writeMetadataDocs(packages) File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line 472, in writeMetadataDocs self.primaryfile.write(po.xml_dump_primary_metadata()) File "/usr/lib/python2.5/site-packages/yum/packages.py", line 943, in xml_dump_primary_metadata msg += misc.to_unicode(self._dump_format_items()) File "/usr/lib/python2.5/site-packages/yum/packages.py", line 809, in _dump_format_items msg += self._dump_pco('provides') UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 38: ordinal not in range(128) Have read around a bit on .spec file character and there looks to be some recommendations but nothing concrete? e.g http://wiki.mandriva.com/en/Policies/Charset#In_spec_file_itself Steve > > -sv > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > -- Steve Traylen From skvidal at fedoraproject.org Wed Mar 18 13:18:23 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 18 Mar 2009 09:18:23 -0400 (EDT) Subject: unicode error with mergerepos against CentOS 5. In-Reply-To: References: Message-ID: On Wed, 18 Mar 2009, Steve Traylen wrote: >> >> the metadata you're pulling in was written with a much older createrepo >> which was less picky about some of the data it wrote back out. So you end up >> with some pkgs with dodgy data in the changelogs. > > Mirroring in CentOS5 and then recreating from scratch the repodirs with a Fedora > 10 createrepo the the repository is created spitting out some warnings. What ver of yum and createrepo do you have when you're running both createrepo and mergerepo? -sv From steve at traylen.net Wed Mar 18 13:23:46 2009 From: steve at traylen.net (Steve Traylen) Date: Wed, 18 Mar 2009 14:23:46 +0100 Subject: unicode error with mergerepos against CentOS 5. In-Reply-To: References: Message-ID: On Wed, Mar 18, 2009 at 2:18 PM, Seth Vidal wrote: > > > On Wed, 18 Mar 2009, Steve Traylen wrote: > >>> >>> the metadata you're pulling in was written with a much older createrepo >>> which was less picky about some of the data it wrote back out. So you end >>> up >>> with some pkgs with dodgy data in the changelogs. >> >> Mirroring in CentOS5 and then recreating from scratch the repodirs with a >> Fedora >> 10 createrepo the the repository is created spitting out some warnings. > > What ver of yum and createrepo do you have when you're running both > createrepo and mergerepo? $ rpm -qf /usr/bin/yum \ /usr/bin/mergerepo \ /usr/bin/createrepo \ /usr/libexec/kojid/mergerepos yum-3.2.21-2.fc10.noarch createrepo-0.9.6-3.fc10.noarch createrepo-0.9.6-3.fc10.noarch koji-builder-1.3.1-1.fc10.noarch > > -sv > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > -- Steve Traylen From jgregusk at redhat.com Wed Mar 18 18:52:35 2009 From: jgregusk at redhat.com (Jay Greguske) Date: Wed, 18 Mar 2009 14:52:35 -0400 Subject: bind-mounting files in mock Message-ID: <49C142F3.1060006@redhat.com> Hello, While trying to get livecd-creator working in a mock-built chroot, I discovered that only directories could be bind-mounted using the bind_mount plugin. I made a few code changes and attached a patch for your consideration that enables the bind-mounting of files. Like directories, the bind-mounting of files will require 'internal_dev_setup' be set to False, otherwise the mount command will fail. In the chroot configuration file the following syntax would be allowed (which looks just like that which was used for bind-mounting directories): config_opts['plugin_conf']['bind_mount_opts']['files'].append(('/dev/loop0', '/dev/loop0')) Please let me know what you think, and thanks in advance for your time! - Jay -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-support-to-bind_mount-files.patch Type: text/x-patch Size: 2567 bytes Desc: not available URL: From steve at traylen.net Fri Mar 27 08:04:07 2009 From: steve at traylen.net (Steve Traylen) Date: Fri, 27 Mar 2009 09:04:07 +0100 Subject: unicode error with mergerepos against CentOS 5. In-Reply-To: References: Message-ID: On Wed, Mar 18, 2009 at 2:23 PM, Steve Traylen wrote: > On Wed, Mar 18, 2009 at 2:18 PM, Seth Vidal wrote: >> >> >> On Wed, 18 Mar 2009, Steve Traylen wrote: >> >>>> >>>> the metadata you're pulling in was written with a much older createrepo >>>> which was less picky about some of the data it wrote back out. So you end >>>> up >>>> with some pkgs with dodgy data in the changelogs. >>> >>> Mirroring in CentOS5 and then recreating from scratch the repodirs with a >>> Fedora >>> 10 createrepo the the repository is created spitting out some warnings. >> >> What ver of yum and createrepo do you have when you're running both >> createrepo and mergerepo? > > $ rpm -qf /usr/bin/yum \ > ? ? ? ? ? ? ?/usr/bin/mergerepo \ > ? ? ? ? ? ? ?/usr/bin/createrepo \ > ? ? ? ? ? ? ?/usr/libexec/kojid/mergerepos > yum-3.2.21-2.fc10.noarch > createrepo-0.9.6-3.fc10.noarch > createrepo-0.9.6-3.fc10.noarch > koji-builder-1.3.1-1.fc10.noarch > Hi Seth, Is there any workaround or anything for this? Steve > > >> >> -sv >> >> -- >> Fedora-buildsys-list mailing list >> Fedora-buildsys-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-buildsys-list >> > > > > -- > Steve Traylen > -- Steve Traylen From williams at redhat.com Fri Mar 27 14:36:18 2009 From: williams at redhat.com (Clark Williams) Date: Fri, 27 Mar 2009 09:36:18 -0500 Subject: bind-mounting files in mock In-Reply-To: <49C142F3.1060006@redhat.com> References: <49C142F3.1060006@redhat.com> Message-ID: <20090327093618.3b5ee361@torg> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 18 Mar 2009 14:52:35 -0400 Jay Greguske wrote: > Hello, > > While trying to get livecd-creator working in a mock-built chroot, I > discovered that only directories could be bind-mounted using the > bind_mount plugin. I made a few code changes and attached a patch for > your consideration that enables the bind-mounting of files. Like > directories, the bind-mounting of files will require > 'internal_dev_setup' be set to False, otherwise the mount command will fail. > > In the chroot configuration file the following syntax would be allowed > (which looks just like that which was used for bind-mounting directories): > > config_opts['plugin_conf']['bind_mount_opts']['files'].append(('/dev/loop0', > '/dev/loop0')) > > Please let me know what you think, and thanks in advance for your time! > > - Jay Jay, Finally got some time to pull in mock patches and work on bugs. Sorry it's taken this long... I'm not seeing how your stuff would work. A bind-mount only works on directories, not files. If I try to bind-mount /dev/loop0 somewhere by hand I get the following: $ mkdir -p /tmp/foo && cd /tmp/foo $ sudo mount -n --bind /dev/loop0 . mount: Not a directory $ mkdir dev $ sudo mount -n --bind /dev/loop0 dev mount: Not a directory What am I missing here? Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknM5GYACgkQHyuj/+TTEp1CWQCgsPClxT4qV2XCQx3oyHihhBlE t9UAoIekmO6wJCgp9T+OwukEguLJ21Qz =63u9 -----END PGP SIGNATURE----- From jgregusk at redhat.com Fri Mar 27 14:39:54 2009 From: jgregusk at redhat.com (Jay Greguske) Date: Fri, 27 Mar 2009 10:39:54 -0400 Subject: bind-mounting files in mock In-Reply-To: <20090327093618.3b5ee361@torg> References: <49C142F3.1060006@redhat.com> <20090327093618.3b5ee361@torg> Message-ID: <49CCE53A.5080602@redhat.com> Hi Clark, If you're bind mounting a file, you have to bind it to an existing file, not a directory. Try touching /dev/myloop first, and then mounting the real loop device to it. Thanks, -jay Clark Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, 18 Mar 2009 14:52:35 -0400 > Jay Greguske wrote: > > >> Hello, >> >> While trying to get livecd-creator working in a mock-built chroot, I >> discovered that only directories could be bind-mounted using the >> bind_mount plugin. I made a few code changes and attached a patch for >> your consideration that enables the bind-mounting of files. Like >> directories, the bind-mounting of files will require >> 'internal_dev_setup' be set to False, otherwise the mount command will fail. >> >> In the chroot configuration file the following syntax would be allowed >> (which looks just like that which was used for bind-mounting directories): >> >> config_opts['plugin_conf']['bind_mount_opts']['files'].append(('/dev/loop0', >> '/dev/loop0')) >> >> Please let me know what you think, and thanks in advance for your time! >> >> - Jay >> > > Jay, > > Finally got some time to pull in mock patches and work on bugs. Sorry > it's taken this long... > > I'm not seeing how your stuff would work. A bind-mount only works on > directories, not files. If I try to bind-mount /dev/loop0 somewhere by > hand I get the following: > > $ mkdir -p /tmp/foo && cd /tmp/foo > $ sudo mount -n --bind /dev/loop0 . > mount: Not a directory > $ mkdir dev > $ sudo mount -n --bind /dev/loop0 dev > mount: Not a directory > > What am I missing here? > > Clark > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) > > iEYEARECAAYFAknM5GYACgkQHyuj/+TTEp1CWQCgsPClxT4qV2XCQx3oyHihhBlE > t9UAoIekmO6wJCgp9T+OwukEguLJ21Qz > =63u9 > -----END PGP SIGNATURE----- > From williams at redhat.com Fri Mar 27 15:37:42 2009 From: williams at redhat.com (Clark Williams) Date: Fri, 27 Mar 2009 10:37:42 -0500 Subject: bind-mounting files in mock In-Reply-To: <49CCE53A.5080602@redhat.com> References: <49C142F3.1060006@redhat.com> <20090327093618.3b5ee361@torg> <49CCE53A.5080602@redhat.com> Message-ID: <20090327103742.2b8da6e2@torg> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wow, that's bizarre (but works). :) It's not described in the man page, so I'm a bit leery about depending on that behavior. That being said, it's not a normal use-case for mock builds, so it'll probably only bite the livecd creation stuff it the bind-mount behavior changes. Ok, I'll pull it in for the next release. Clark On Fri, 27 Mar 2009 10:39:54 -0400 Jay Greguske wrote: > Hi Clark, > > If you're bind mounting a file, you have to bind it to an existing file, > not a directory. Try touching /dev/myloop first, and then mounting the > real loop device to it. > > Thanks, > -jay > > > Clark Williams wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Wed, 18 Mar 2009 14:52:35 -0400 > > Jay Greguske wrote: > > > > > >> Hello, > >> > >> While trying to get livecd-creator working in a mock-built chroot, I > >> discovered that only directories could be bind-mounted using the > >> bind_mount plugin. I made a few code changes and attached a patch for > >> your consideration that enables the bind-mounting of files. Like > >> directories, the bind-mounting of files will require > >> 'internal_dev_setup' be set to False, otherwise the mount command will fail. > >> > >> In the chroot configuration file the following syntax would be allowed > >> (which looks just like that which was used for bind-mounting directories): > >> > >> config_opts['plugin_conf']['bind_mount_opts']['files'].append(('/dev/loop0', > >> '/dev/loop0')) > >> > >> Please let me know what you think, and thanks in advance for your time! > >> > >> - Jay > >> > > > > Jay, > > > > Finally got some time to pull in mock patches and work on bugs. Sorry > > it's taken this long... > > > > I'm not seeing how your stuff would work. A bind-mount only works on > > directories, not files. If I try to bind-mount /dev/loop0 somewhere by > > hand I get the following: > > > > $ mkdir -p /tmp/foo && cd /tmp/foo > > $ sudo mount -n --bind /dev/loop0 . > > mount: Not a directory > > $ mkdir dev > > $ sudo mount -n --bind /dev/loop0 dev > > mount: Not a directory > > > > What am I missing here? > > > > Clark > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2.0.9 (GNU/Linux) > > > > iEYEARECAAYFAknM5GYACgkQHyuj/+TTEp1CWQCgsPClxT4qV2XCQx3oyHihhBlE > > t9UAoIekmO6wJCgp9T+OwukEguLJ21Qz > > =63u9 > > -----END PGP SIGNATURE----- > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknM8swACgkQHyuj/+TTEp2i/QCfZa1y4KBC2z4A3ZP9+rO8muZF Q3gAoItg2iK5NMf9vnfVLgaT4BSTWhLC =j3Sw -----END PGP SIGNATURE----- From jkeating at redhat.com Fri Mar 27 15:57:17 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 27 Mar 2009 08:57:17 -0700 Subject: bind-mounting files in mock In-Reply-To: <20090327103742.2b8da6e2@torg> References: <49C142F3.1060006@redhat.com> <20090327093618.3b5ee361@torg> <49CCE53A.5080602@redhat.com> <20090327103742.2b8da6e2@torg> Message-ID: <1238169437.3726.5.camel@localhost.localdomain> On Fri, 2009-03-27 at 10:37 -0500, Clark Williams wrote: > It's not described in the man page, so I'm a bit leery about depending > on that behavior. That being said, it's not a normal use-case for mock > builds, so it'll probably only bite the livecd creation stuff it the > bind-mount behavior changes. > > Ok, I'll pull it in for the next release. I need that functionality too when building install images. Rather than see more and different code paths when chroot generating, I think there would be some value in using the same code path regardless of how the chroot is used. I think the bind mounting of dev/ is only there for the loop entries, I don't know of any other mock consumers that require a real /dev/ tree. We might consider just always file bind mounting a few loop entries in and only having one code path. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Fri Mar 27 17:42:55 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 27 Mar 2009 13:42:55 -0400 (EDT) Subject: unicode error with mergerepos against CentOS 5. In-Reply-To: References: Message-ID: On Fri, 27 Mar 2009, Steve Traylen wrote: > On Wed, Mar 18, 2009 at 2:23 PM, Steve Traylen wrote: >> On Wed, Mar 18, 2009 at 2:18 PM, Seth Vidal wrote: >>> >>> >>> On Wed, 18 Mar 2009, Steve Traylen wrote: >>> >>>>> >>>>> the metadata you're pulling in was written with a much older createrepo >>>>> which was less picky about some of the data it wrote back out. So you end >>>>> up >>>>> with some pkgs with dodgy data in the changelogs. >>>> >>>> Mirroring in CentOS5 and then recreating from scratch the repodirs with a >>>> Fedora >>>> 10 createrepo the the repository is created spitting out some warnings. >>> >>> What ver of yum and createrepo do you have when you're running both >>> createrepo and mergerepo? >> >> $ rpm -qf /usr/bin/yum \ >> ? ? ? ? ? ? ?/usr/bin/mergerepo \ >> ? ? ? ? ? ? ?/usr/bin/createrepo \ >> ? ? ? ? ? ? ?/usr/libexec/kojid/mergerepos >> yum-3.2.21-2.fc10.noarch >> createrepo-0.9.6-3.fc10.noarch >> createrepo-0.9.6-3.fc10.noarch >> koji-builder-1.3.1-1.fc10.noarch >> > > Hi Seth, > > Is there any workaround or anything for this? > > Steve I doubt it'll help much - but try 0.9.7 and 3.2.22 that are in rawhide. We fixed a few more unicode explosions but I'm sure we're still missing some -sv From williams at redhat.com Fri Mar 27 18:14:08 2009 From: williams at redhat.com (Clark Williams) Date: Fri, 27 Mar 2009 13:14:08 -0500 Subject: bind-mounting files in mock In-Reply-To: <1238169437.3726.5.camel@localhost.localdomain> References: <49C142F3.1060006@redhat.com> <20090327093618.3b5ee361@torg> <49CCE53A.5080602@redhat.com> <20090327103742.2b8da6e2@torg> <1238169437.3726.5.camel@localhost.localdomain> Message-ID: <20090327131408.2cb31bb1@torg> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 27 Mar 2009 08:57:17 -0700 Jesse Keating wrote: > On Fri, 2009-03-27 at 10:37 -0500, Clark Williams wrote: > > It's not described in the man page, so I'm a bit leery about depending > > on that behavior. That being said, it's not a normal use-case for mock > > builds, so it'll probably only bite the livecd creation stuff it the > > bind-mount behavior changes. > > > > Ok, I'll pull it in for the next release. > > I need that functionality too when building install images. Rather than > see more and different code paths when chroot generating, I think there > would be some value in using the same code path regardless of how the > chroot is used. I think the bind mounting of dev/ is only there for the > loop entries, I don't know of any other mock consumers that require a > real /dev/ tree. We might consider just always file bind mounting a few > loop entries in and only having one code path. That works for me. I'm currently trying to figure out the regression with 3rd party repos, so if you have the time and can gin up a patch, that'd be great; if not I'll work on it after I figure the BZ out. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknNF3QACgkQHyuj/+TTEp2kZgCfdrRSiGQLWukV3OT03EXFosZv 8VEAoLmdboXfdgVafNi7SYgfz4qnc+KZ =qdbd -----END PGP SIGNATURE----- From katzj at redhat.com Fri Mar 27 18:24:57 2009 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 27 Mar 2009 14:24:57 -0400 Subject: bind-mounting files in mock In-Reply-To: <1238169437.3726.5.camel@localhost.localdomain> References: <49C142F3.1060006@redhat.com> <20090327093618.3b5ee361@torg> <49CCE53A.5080602@redhat.com> <20090327103742.2b8da6e2@torg> <1238169437.3726.5.camel@localhost.localdomain> Message-ID: <20090327182456.GA23006@redhat.com> On Friday, March 27 2009, Jesse Keating said: > On Fri, 2009-03-27 at 10:37 -0500, Clark Williams wrote: > > It's not described in the man page, so I'm a bit leery about depending > > on that behavior. That being said, it's not a normal use-case for mock > > builds, so it'll probably only bite the livecd creation stuff it the > > bind-mount behavior changes. > > > > Ok, I'll pull it in for the next release. > > I need that functionality too when building install images. Rather than > see more and different code paths when chroot generating, I think there > would be some value in using the same code path regardless of how the > chroot is used. I think the bind mounting of dev/ is only there for the > loop entries, I don't know of any other mock consumers that require a > real /dev/ tree. We might consider just always file bind mounting a few > loop entries in and only having one code path. You can't really just do a few as you may need however many there are on the real system. If the idea is to make them by default it's probably better to just make n of them based on the host. But then the chroot does have a way of affecting outside of it :/ Jeremy From wacker at octothorp.org Fri Mar 27 19:44:43 2009 From: wacker at octothorp.org (William F. Acker WB2FLW +1 303 722 7209) Date: Fri, 27 Mar 2009 13:44:43 -0600 (MDT) Subject: Error from repoview when composing with pungi. In-Reply-To: <1235001752.16686.160.camel@rosebud> References: <1234973794.16686.111.camel@rosebud> <1234993395.16686.141.camel@rosebud> <1235001752.16686.160.camel@rosebud> Message-ID: On Wed, 18 Feb 2009, seth vidal wrote: > On Wed, 2009-02-18 at 16:43 -0500, seth vidal wrote: >> On Wed, 2009-02-18 at 14:35 -0700, William F. Acker WB2FLW +1 303 722 >> 7209 wrote: >> >>> I back leveled sqlite on the build machine which didn't help. I know >>> that's not conclusive since some packages such as Anaconda are downloaded >>> from the repo and never cached. So, before putting the old sqlite into >>> the repo, I checked to see the when I was last successful VS when I >>> installed sqlite. It turns out that both yum and sqlite were installed on >>> 2/5, and my last successful spin was on 2/8. I don't see any packages >>> installed since them that are obviously connected to this problem. >>> >> >> I'm not sure if this is sqlite anymore - I've been mucking with it >> today. Oddly on rawhide here I can't make it happen. >> >> > > ah ha! My sample size was too small. I found out what was causing the > problem > > somehow we had two packages VLGothic-fonts and vlgothic-fonts - repoview > case normalizes for the .html files it makes - hence this problem. > Fedora was not supposed to have those two pkgs - it was an oversight and > that has been fixed. I'll also change repoview to not case normalize the > filenames. > The new repoview did the trick. On F9 and F10, the install media built quite nicely. I haven't installed from them yet, but I don't see any reason why there'd be a problem with that. Thanks a gig! -- Bill in Denver From steve at traylen.net Fri Mar 27 21:44:19 2009 From: steve at traylen.net (Steve Traylen) Date: Fri, 27 Mar 2009 22:44:19 +0100 Subject: unicode error with mergerepos against CentOS 5. In-Reply-To: References: Message-ID: 2009/3/27 Seth Vidal : > > > On Fri, 27 Mar 2009, Steve Traylen wrote: > >> On Wed, Mar 18, 2009 at 2:23 PM, Steve Traylen wrote: >>> >>> On Wed, Mar 18, 2009 at 2:18 PM, Seth Vidal >>> wrote: >>>> >>>> >>>> On Wed, 18 Mar 2009, Steve Traylen wrote: >>>> >>>>>> >>>>>> the metadata you're pulling in was written with a much older >>>>>> createrepo >>>>>> which was less picky about some of the data it wrote back out. So you >>>>>> end >>>>>> up >>>>>> with some pkgs with dodgy data in the changelogs. >>>>> >>>>> Mirroring in CentOS5 and then recreating from scratch the repodirs with >>>>> a >>>>> Fedora >>>>> 10 createrepo the the repository is created spitting out some warnings. >>>> >>>> What ver of yum and createrepo do you have when you're running both >>>> createrepo and mergerepo? >>> >>> $ rpm -qf /usr/bin/yum \ >>> ? ? ? ? ? ? ?/usr/bin/mergerepo \ >>> ? ? ? ? ? ? ?/usr/bin/createrepo \ >>> ? ? ? ? ? ? ?/usr/libexec/kojid/mergerepos >>> yum-3.2.21-2.fc10.noarch >>> createrepo-0.9.6-3.fc10.noarch >>> createrepo-0.9.6-3.fc10.noarch >>> koji-builder-1.3.1-1.fc10.noarch >>> >> >> Hi Seth, >> >> Is there any workaround or anything for this? >> >> ? Steve > > I doubt it'll help much - but try 0.9.7 and 3.2.22 that ?are in rawhide. We > fixed a few more unicode explosions but I'm sure we're still missing some > > -sv Same with rawhide. Workaround , removing by hand the copyright symbol present in primary.xml. recorded here: http://createrepo.baseurl.org/ticket/3 > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > -- Steve Traylen