From mikem at redhat.com Tue Sep 1 18:54:39 2009 From: mikem at redhat.com (Mike McLean) Date: Tue, 01 Sep 2009 14:54:39 -0400 Subject: about repo In-Reply-To: <29677371.92221251772282541.JavaMail.coremail@bj163app93.163.com> References: <29677371.92221251772282541.JavaMail.coremail@bj163app93.163.com> Message-ID: <4A9D6DEF.3090701@redhat.com> Please keep these discussions on fedora-buildsys-list On 08/31/2009 10:31 PM, lixiao-a wrote: > Dear Mike, > Hello,my hosts in the createrepo channel have all access to /mnt/koji,so I doult the reason is the third one.It is that createrepo jobs are failing.The logs are as follows, I'm afraid all this traceback tells me is that the repodata dir is missing. Have you looked at the logs of the failing createrepo task? There should be a createrepo.log. If there is not one, then it may be your tag is misconfigured. Is there content in the build tag? > 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/227/227/repo/repodata\' > Thanks for your help and your reply! From tan20bk at yahoo.com Thu Sep 3 11:31:37 2009 From: tan20bk at yahoo.com (NGUYEN VAN TAN) Date: Thu, 3 Sep 2009 04:31:37 -0700 (PDT) Subject: Can't Create repos Message-ID: <532535.63316.qm@web62403.mail.re1.yahoo.com> I'm trying to construct koji-server on Fedora 10, but I got an error. Kojira can't create repos. It is always failed when try to create repos. 2009-09-03 14:06:44,449 [INFO] koji.repo.manager: Created newRepo task 116 for tag 2 (dist-foo-build) 2009-09-03 14:07:00,198 [INFO] koji.repo.manager: Found repo 24, state=INIT 2009-09-03 14:07:16,096 [INFO] koji.repo.manager: Problem: newRepo task 116 for tag 2 is FAILED 2009-09-03 14:10:00,128 [INFO] koji.repo.manager: Created newRepo task 121 for tag 2 (dist-foo-build) 2009-09-03 14:10:05,331 [INFO] koji.repo.manager: Problem: newRepo task 121 for tag 2 is FAILED 2009-09-03 14:10:05,397 [INFO] koji.repo.manager: Found repo 25, state=INIT [root at localhost kojibuilder1]# tail /var/log/kojira.log 2009-09-03 14:07:16,096 [INFO] koji.repo.manager: Problem: newRepo task 116 for tag 2 is FAILED 2009-09-03 14:10:00,128 [INFO] koji.repo.manager: Created newRepo task 121 for tag 2 (dist-foo-build) 2009-09-03 14:10:05,331 [INFO] koji.repo.manager: Problem: newRepo task 121 for tag 2 is FAILED 2009-09-03 14:10:05,397 [INFO] koji.repo.manager: Found repo 25, state=INIT 2009-09-03 14:13:05,745 [INFO] koji.repo.manager: Created newRepo task 128 for tag 2 (dist-foo-build) 2009-09-03 14:13:21,376 [INFO] koji.repo.manager: Found repo 26, state=INIT 2009-09-03 14:13:37,095 [INFO] koji.repo.manager: Problem: newRepo task 128 for tag 2 is FAILED 2009-09-03 14:16:23,676 [INFO] koji.repo.manager: Created newRepo task 133 for tag 2 (dist-foo-build) 2009-09-03 14:16:39,445 [INFO] koji.repo.manager: Problem: newRepo task 133 for tag 2 is FAILED 2009-09-03 14:16:39,492 [INFO] koji.repo.manager: Found repo 27, state=INIT Anyone got this error? And Could you tell me how to solve it? Thanks in advance. ? Nguy?n V?n T?n Thi?t k? ngay m?t Pingbox ??c ??o cho ri?ng b?n! T?o m?t n?i ?? chat tr?n blog l? chuy?n nh?. http://vn.messenger.yahoo.com/pingbox/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rotru at br.ibm.com Thu Sep 3 12:13:51 2009 From: rotru at br.ibm.com (rotru at br.ibm.com) Date: Thu, 3 Sep 2009 09:13:51 -0300 Subject: Can't Create repos In-Reply-To: <532535.63316.qm@web62403.mail.re1.yahoo.com> References: <532535.63316.qm@web62403.mail.re1.yahoo.com> Message-ID: I have already had this problem. Re-check the repo directory permission (usually in /mnt/koji) and selinux linux permissions as well. I have selinux disabled, to avoid problems. I may find more usefull information in kojid.log. Rodrigo Trujillo From: NGUYEN VAN TAN To: fedora-buildsys-list at redhat.com Date: 03/09/2009 08:29 Subject: Can't Create repos I'm trying to construct koji-server on Fedora 10, but I got an error. Kojira can't create repos. It is always failed when try to create repos. 2009-09-03 14:06:44,449 [INFO] koji.repo.manager: Created newRepo task 116 for tag 2 (dist-foo-build) 2009-09-03 14:07:00,198 [INFO] koji.repo.manager: Found repo 24, state=INIT 2009-09-03 14:07:16,096 [INFO] koji.repo.manager: Problem: newRepo task 116 for tag 2 is FAILED 2009-09-03 14:10:00,128 [INFO] koji.repo.manager: Created newRepo task 121 for tag 2 (dist-foo-build) 2009-09-03 14:10:05,331 [INFO] koji.repo.manager: Problem: newRepo task 121 for tag 2 is FAILED 2009-09-03 14:10:05,397 [INFO] koji.repo.manager: Found repo 25, state=INIT [root at localhost kojibuilder1]# tail /var/log/kojira.log 2009-09-03 14:07:16,096 [INFO] koji.repo.manager: Problem: newRepo task 116 for tag 2 is FAILED 2009-09-03 14:10:00,128 [INFO] koji.repo.manager: Created newRepo task 121 for tag 2 (dist-foo-build) 2009-09-03 14:10:05,331 [INFO] koji.repo.manager: Problem: newRepo task 121 for tag 2 is FAILED 2009-09-03 14:10:05,397 [INFO] koji.repo.manager: Found repo 25, state=INIT 2009-09-03 14:13:05,745 [INFO] koji.repo.manager: Created newRepo task 128 for tag 2 (dist-foo-build) 2009-09-03 14:13:21,376 [INFO] koji.repo.manager: Found repo 26, state=INIT 2009-09-03 14:13:37,095 [INFO] koji.repo.manager: Problem: newRepo task 128 for tag 2 is FAILED 2009-09-03 14:16:23,676 [INFO] koji.repo.manager: Created newRepo task 133 for tag 2 (dist-foo-build) 2009-09-03 14:16:39,445 [INFO] koji.repo.manager: Problem: newRepo task 133 for tag 2 is FAILED 2009-09-03 14:16:39,492 [INFO] koji.repo.manager: Found repo 27, state=INIT Anyone got this error? And Could you tell me how to solve it? Thanks in advance. Nguy?n V?n T?n Yahoo! Mail nay NHANH H?N - Th? ngay!-- 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 walter.franzini at gmail.com Fri Sep 4 15:26:48 2009 From: walter.franzini at gmail.com (Walter Franzini) Date: Fri, 04 Sep 2009 17:26:48 +0200 Subject: mock tarball download Message-ID: <873a72ennr.fsf@walter-nb.nord-com.it> Hi, I'm considering to adopt the recently orphaned mock Debian package, where can I get the tarball for the latest version (0.9.17 looking in the git repository)? The "official" download page (https://fedorahosted.org/mock/wiki/MockTarballs) has 0.9.10 as the most recent release. Thanks. -- Walter Franzini http://aegis.stepbuild.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From skvidal at fedoraproject.org Fri Sep 4 20:41:56 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 4 Sep 2009 16:41:56 -0400 (EDT) Subject: mock tarball download In-Reply-To: <873a72ennr.fsf@walter-nb.nord-com.it> References: <873a72ennr.fsf@walter-nb.nord-com.it> Message-ID: On Fri, 4 Sep 2009, Walter Franzini wrote: > Hi, > > I'm considering to adopt the recently orphaned mock Debian package, > where can I get the tarball for the latest version (0.9.17 looking in > the git repository)? > > The "official" download page > (https://fedorahosted.org/mock/wiki/MockTarballs) has 0.9.10 as the most > recent release. here's where they [c|sh]ould be: https://fedorahosted.org/releases/m/o/mock/ but they don't appear to have been uploaded there. -sv From jkeating at redhat.com Fri Sep 4 20:49:27 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 04 Sep 2009 13:49:27 -0700 Subject: mock tarball download In-Reply-To: References: <873a72ennr.fsf@walter-nb.nord-com.it> Message-ID: <1252097367.2318.13.camel@localhost.localdomain> On Fri, 2009-09-04 at 16:41 -0400, Seth Vidal wrote: > here's where they [c|sh]ould be: > https://fedorahosted.org/releases/m/o/mock/ > > but they don't appear to have been uploaded there. We've been lazy about putting the tarball up, since we do releases from git tags. -- 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: 198 bytes Desc: This is a digitally signed message part URL: From tan20bk at yahoo.com Sun Sep 6 11:34:56 2009 From: tan20bk at yahoo.com (NGUYEN VAN TAN) Date: Sun, 6 Sep 2009 04:34:56 -0700 (PDT) Subject: =?utf-8?q?V=E1=BB=81=3A_Fedora-buildsys-list_Digest=2C_Vol_55=2C?= =?utf-8?q?_Issue_2?= In-Reply-To: <20090903160010.3AF0B61A4AD@hormel.redhat.com> Message-ID: <361316.30002.qm@web62408.mail.re1.yahoo.com> Thank you, I saw kojid log, but I don't understand what it mean. 2009-09-06 14:18:54,311 [INFO] koji.build.TaskManager: open task: {'waiting': True, 'id': 7, 'weight': 0.10000000000000001} 2009-09-06 14:18:54,398 [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/8/8/repo/repodata' 2009-09-06 14:18:54,450 [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/9/9/repo/repodata' 2009-09-06 14:19:09,407 [INFO] koji.build.TaskManager: pids: {7: 10867, 8: 10873, 9: 10877} 2009-09-06 14:19:09,417 [INFO] koji.build.TaskManager: open task: {'waiting': True, 'id': 7, 'weight': 0.10000000000000001, 'alert': True} 2009-09-06 14:19:09,418 [INFO] koji.build.TaskManager: Waking up task: {'waiting': True, 'id': 7, 'weight': 0.10000000000000001, 'alert': True} 2009-09-06 14:19:09,424 [INFO] koji.build.TaskManager: Task 8 (pid 10873) exited with status 0 2009-09-06 14:19:09,582 [WARNING] koji.build.TaskManager: FAULT: 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 2517, in handler ??? results = self.wait(subtasks.values(), all=True, failany=True) ? File "/usr/sbin/kojid", line 1438, in wait ??? return dict(session.host.taskWaitResults(self.id,subtasks)) ? File "/usr/lib/python2.5/site-packages/koji/__init__.py", line 1255, in __call__ ??? return self.__func(self.__name,args,opts) ? File "/usr/lib/python2.5/site-packages/koji/__init__.py", line 1501, in _callMethod ??? raise err Fault: 2009-09-06 14:19:09,610 [INFO] koji.build.TaskManager: Expiring subsession 27 (task 8) 2009-09-06 14:19:09,666 [INFO] koji.build.TaskManager: Task 9 (pid 10877) exited with status 0 2009-09-06 14:19:09,694 [INFO] koji.build.TaskManager: Expiring subsession 28 (task 9) 2009-09-06 14:19:25,813 [INFO] koji.build.TaskManager: pids: {7: 10867} 2009-09-06 14:19:25,943 [INFO] koji.build.TaskManager: Task 7 (pid 10867) exited with status 0 2009-09-06 14:19:25,973 [INFO] koji.build.TaskManager: Expiring subsession 26 (task 7) I also saw kojira log, but I can't find the what problem is. 2009-09-06 13:09:23,652 [INFO] koji.repo.manager: Found repo 24, state=INIT 2009-09-06 13:10:07,760 [INFO] koji.repo.manager: Problem: newRepo task 116 for tag 2 is FAILED 2009-09-06 13:12:19,724 [INFO] koji.repo.manager: Created newRepo task 121 for tag 2 (dist-foo-build) 2009-09-06 13:12:25,373 [INFO] koji.repo.manager: Found repo 25, state=INIT 2009-09-06 13:12:32,349 [INFO] koji.repo.manager: Problem: newRepo task 121 for tag 2 is FAILED 2009-09-06 14:07:52,959 [INFO] koji: Entering main loop 2009-09-06 14:14:26,191 [INFO] koji.repo.manager: Created newRepo task 1 for tag 2 (dist-foo-build) 2009-09-06 14:14:36,261 [INFO] koji.repo.manager: Found repo 1, state=INIT 2009-09-06 14:15:06,624 [INFO] koji.repo.manager: Problem: newRepo task 1 for tag 2 is FAILED 2009-09-06 14:15:06,654 [INFO] koji.repo.manager: Created newRepo task 4 for tag 2 (dist-foo-build) 2009-09-06 14:15:21,807 [INFO] koji.repo.manager: Problem: newRepo task 4 for tag 2 is FAILED 2009-09-06 14:15:21,868 [INFO] koji.repo.manager: Found repo 2, state=INIT 2009-09-06 14:18:24,378 [INFO] koji.repo.manager: Created newRepo task 7 for tag 2 (dist-foo-build) 2009-09-06 14:18:43,487 [INFO] koji.repo.manager: Found repo 3, state=INIT 2009-09-06 14:19:11,220 [INFO] koji.repo.manager: Problem: newRepo task 7 for tag 2 is FAILED 2009-09-06 14:21:41,670 [INFO] koji.repo.manager: Created newRepo task 10 for tag 2 (dist-foo-build) 2009-09-06 14:22:01,882 [INFO] koji.repo.manager: Found repo 4, state=INIT 2009-09-06 14:22:17,139 [INFO] koji.repo.manager: Problem: newRepo task 10 for tag 2 is FAILED I checked if /tmp/koji/tasks/8/8/repo/repodata? exist and this folder is not exist. Do you know this folder would be created by what kind of component and Why it could be created yet? And when here my tasks ID??? Pri? Owner??????? State??? Arch?????? Name 1???? 15?? kojira?????? FAILED?? noarch???? newRepo [kojibuilder1] 2???? 14?? kojira?????? FAILED?? noarch????? +createrepo [kojibuilder1] 3???? 14?? kojira?????? FAILED?? noarch????? +createrepo [kojibuilder1] 4???? 15?? kojira?????? FAILED?? noarch???? newRepo [kojibuilder1] 5???? 14?? kojira?????? FAILED?? noarch????? +createrepo [kojibuilder1] 6???? 14?? kojira?????? CANCELED noarch????? +createrepo [kojibuilder1] Do you know why kojira can't create repos and solution to solve it. Thanks in advance Nguy?n V?n T?n --- Ng?y Th? 5, 3/09/09, fedora-buildsys-list-request at redhat.com ?? vi?t: T?: fedora-buildsys-list-request at redhat.com Ch? ??: Fedora-buildsys-list Digest, Vol 55, Issue 2 ??n: fedora-buildsys-list at redhat.com Ng?y: Th? N?m, 3 th?ng 9, 2009, 23:00 Send Fedora-buildsys-list mailing list submissions to ??? fedora-buildsys-list at redhat.com To subscribe or unsubscribe via the World Wide Web, visit ??? https://www.redhat.com/mailman/listinfo/fedora-buildsys-list or, via email, send a message with subject or body 'help' to ??? fedora-buildsys-list-request at redhat.com You can reach the person managing the list at ??? fedora-buildsys-list-owner at redhat.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Fedora-buildsys-list digest..." Today's Topics: ???1. Can't Create repos (NGUYEN VAN TAN) ???2. Re: Can't Create repos (rotru at br.ibm.com) ---------------------------------------------------------------------- Message: 1 Date: Thu, 3 Sep 2009 04:31:37 -0700 (PDT) From: NGUYEN VAN TAN Subject: Can't Create repos To: fedora-buildsys-list at redhat.com Message-ID: <532535.63316.qm at web62403.mail.re1.yahoo.com> Content-Type: text/plain; charset="utf-8" I'm trying to construct koji-server on Fedora 10, but I got an error. Kojira can't create repos. It is always failed when try to create repos. 2009-09-03 14:06:44,449 [INFO] koji.repo.manager: Created newRepo task 116 for tag 2 (dist-foo-build) 2009-09-03 14:07:00,198 [INFO] koji.repo.manager: Found repo 24, state=INIT 2009-09-03 14:07:16,096 [INFO] koji.repo.manager: Problem: newRepo task 116 for tag 2 is FAILED 2009-09-03 14:10:00,128 [INFO] koji.repo.manager: Created newRepo task 121 for tag 2 (dist-foo-build) 2009-09-03 14:10:05,331 [INFO] koji.repo.manager: Problem: newRepo task 121 for tag 2 is FAILED 2009-09-03 14:10:05,397 [INFO] koji.repo.manager: Found repo 25, state=INIT [root at localhost kojibuilder1]# tail /var/log/kojira.log 2009-09-03 14:07:16,096 [INFO] koji.repo.manager: Problem: newRepo task 116 for tag 2 is FAILED 2009-09-03 14:10:00,128 [INFO] koji.repo.manager: Created newRepo task 121 for tag 2 (dist-foo-build) 2009-09-03 14:10:05,331 [INFO] koji.repo.manager: Problem: newRepo task 121 for tag 2 is FAILED 2009-09-03 14:10:05,397 [INFO] koji.repo.manager: Found repo 25, state=INIT 2009-09-03 14:13:05,745 [INFO] koji.repo.manager: Created newRepo task 128 for tag 2 (dist-foo-build) 2009-09-03 14:13:21,376 [INFO] koji.repo.manager: Found repo 26, state=INIT 2009-09-03 14:13:37,095 [INFO] koji.repo.manager: Problem: newRepo task 128 for tag 2 is FAILED 2009-09-03 14:16:23,676 [INFO] koji.repo.manager: Created newRepo task 133 for tag 2 (dist-foo-build) 2009-09-03 14:16:39,445 [INFO] koji.repo.manager: Problem: newRepo task 133 for tag 2 is FAILED 2009-09-03 14:16:39,492 [INFO] koji.repo.manager: Found repo 27, state=INIT Anyone got this error? And Could you tell me how to solve it? Thanks in advance. ? Nguy?n V?n T?n ? ? ? Thi?t k? ngay m?t Pingbox ??c ??o cho ri?ng b?n! T?o m?t n?i ?? chat tr?n blog l? chuy?n nh?. http://vn.messenger.yahoo.com/pingbox/ -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www.redhat.com/archives/fedora-buildsys-list/attachments/20090903/12fd41f9/attachment.html ------------------------------ Message: 2 Date: Thu, 3 Sep 2009 09:13:51 -0300 From: rotru at br.ibm.com Subject: Re: Can't Create repos To: tannv84 at gmail.com,??? Discussion of Fedora build system ??? Message-ID: ??? Content-Type: text/plain; charset="utf-8" I have already had this problem. Re-check the repo directory permission (usually in /mnt/koji) and selinux linux permissions as well. I have selinux disabled, to avoid problems. I may find more usefull information in kojid.log. Rodrigo Trujillo From: NGUYEN VAN TAN To: fedora-buildsys-list at redhat.com Date: 03/09/2009 08:29 Subject: Can't Create repos I'm trying to construct koji-server on Fedora 10, but I got an error. Kojira can't create repos. It is always failed when try to create repos. 2009-09-03 14:06:44,449 [INFO] koji.repo.manager: Created newRepo task 116 for tag 2 (dist-foo-build) 2009-09-03 14:07:00,198 [INFO] koji.repo.manager: Found repo 24, state=INIT 2009-09-03 14:07:16,096 [INFO] koji.repo.manager: Problem: newRepo task 116 for tag 2 is FAILED 2009-09-03 14:10:00,128 [INFO] koji.repo.manager: Created newRepo task 121 for tag 2 (dist-foo-build) 2009-09-03 14:10:05,331 [INFO] koji.repo.manager: Problem: newRepo task 121 for tag 2 is FAILED 2009-09-03 14:10:05,397 [INFO] koji.repo.manager: Found repo 25, state=INIT [root at localhost kojibuilder1]# tail /var/log/kojira.log 2009-09-03 14:07:16,096 [INFO] koji.repo.manager: Problem: newRepo task 116 for tag 2 is FAILED 2009-09-03 14:10:00,128 [INFO] koji.repo.manager: Created newRepo task 121 for tag 2 (dist-foo-build) 2009-09-03 14:10:05,331 [INFO] koji.repo.manager: Problem: newRepo task 121 for tag 2 is FAILED 2009-09-03 14:10:05,397 [INFO] koji.repo.manager: Found repo 25, state=INIT 2009-09-03 14:13:05,745 [INFO] koji.repo.manager: Created newRepo task 128 for tag 2 (dist-foo-build) 2009-09-03 14:13:21,376 [INFO] koji.repo.manager: Found repo 26, state=INIT 2009-09-03 14:13:37,095 [INFO] koji.repo.manager: Problem: newRepo task 128 for tag 2 is FAILED 2009-09-03 14:16:23,676 [INFO] koji.repo.manager: Created newRepo task 133 for tag 2 (dist-foo-build) 2009-09-03 14:16:39,445 [INFO] koji.repo.manager: Problem: newRepo task 133 for tag 2 is FAILED 2009-09-03 14:16:39,492 [INFO] koji.repo.manager: Found repo 27, state=INIT Anyone got this error? And Could you tell me how to solve it? Thanks in advance. Nguy?n V?n T?n Yahoo! Mail nay NHANH H?N - Th? ngay!-- 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: https://www.redhat.com/archives/fedora-buildsys-list/attachments/20090903/6a598143/attachment.html ------------------------------ -- Fedora-buildsys-list mailing list Fedora-buildsys-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list End of Fedora-buildsys-list Digest, Vol 55, Issue 2 *************************************************** n? ngh? g? khi ??n ?ng r?a b?t v? gi?t qu?n ?o? Xem m?i ng??i ngh? g? tr?n Yahoo! H?i & ??p. http://vn.answers.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From arthur.lutz at logilab.fr Mon Sep 7 14:41:27 2009 From: arthur.lutz at logilab.fr (Arthur Lutz) Date: Mon, 7 Sep 2009 16:41:27 +0200 Subject: Offline installation with 3rd party repositories Message-ID: <20090907144127.GK32583@crater.logilab.fr> Hi, I'm using pungi to generate an installer, and now that I've added third party repos and corresponding packages, it doesn't seem to work. The pungi command doesn't complain too much, but when launching the installer in a disconnected virtual machine, after the partitionning I get a "Some repos require network access". Is pungi supposed to handle this usecase scenario ? If so where should I look to correct this bug ? Thanks in advance. Arthur -- Arthur LUTZ LOGILAB, Paris (France) http://www.logilab.com http://www.logilab.fr http://www.logilab.org D?veloppement logiciel avanc? - Intelligence Artificielle - Formations CubicWeb, the semantic web framework: http://www.cubicweb.org From mikeb at redhat.com Tue Sep 8 14:19:18 2009 From: mikeb at redhat.com (Mike Bonnet) Date: Tue, 08 Sep 2009 10:19:18 -0400 Subject: =?utf-8?q?V=E1=BB=81=3A_Fedora-buildsys-list_Digest=2C_Vol_55?= =?utf-8?q?=2C_Issue_2?= In-Reply-To: <361316.30002.qm@web62408.mail.re1.yahoo.com> References: <361316.30002.qm@web62408.mail.re1.yahoo.com> Message-ID: <4AA667E6.7060507@redhat.com> On 09/06/2009 07:34 AM, NGUYEN VAN TAN wrote: > Thank you, I saw kojid log, but I don't understand what it mean. > > 2009-09-06 14:18:54,311 [INFO] koji.build.TaskManager: open task: {'waiting': True, 'id': 7, 'weight': 0.10000000000000001} > 2009-09-06 14:18:54,398 [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/8/8/repo/repodata' > > 2009-09-06 14:18:54,450 [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/9/9/repo/repodata' Do you have any packages or external repos associated with the tag you're trying to create a repo for? If not, then createrepo will never get called, and it won't create the repodata/ subdirectory. Add a package or external repo to the tag, and newRepo/createrepo tasks should start succeeding. > 2009-09-06 14:19:09,407 [INFO] koji.build.TaskManager: pids: {7: 10867, 8: 10873, 9: 10877} > 2009-09-06 14:19:09,417 [INFO] koji.build.TaskManager: open task: {'waiting': True, 'id': 7, 'weight': 0.10000000000000001, 'alert': True} > 2009-09-06 14:19:09,418 [INFO] koji.build.TaskManager: Waking up task: {'waiting': True, 'id': 7, 'weight': 0.10000000000000001, 'alert': True} > 2009-09-06 14:19:09,424 [INFO] koji.build.TaskManager: Task 8 (pid 10873) exited with status 0 > 2009-09-06 14:19:09,582 [WARNING] koji.build.TaskManager: FAULT: > 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 2517, in handler > results = self.wait(subtasks.values(), all=True, failany=True) > File "/usr/sbin/kojid", line 1438, in wait > return dict(session.host.taskWaitResults(self.id,subtasks)) > File "/usr/lib/python2.5/site-packages/koji/__init__.py", line 1255, in __call__ > return self.__func(self.__name,args,opts) > File "/usr/lib/python2.5/site-packages/koji/__init__.py", line 1501, in _callMethod > raise err > Fault: 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/8/8/repo/repodata\' > '> > > 2009-09-06 14:19:09,610 [INFO] koji.build.TaskManager: Expiring subsession 27 (task 8) > 2009-09-06 14:19:09,666 [INFO] koji.build.TaskManager: Task 9 (pid 10877) exited with status 0 > 2009-09-06 14:19:09,694 [INFO] koji.build.TaskManager: Expiring subsession 28 (task 9) > 2009-09-06 14:19:25,813 [INFO] koji.build.TaskManager: pids: {7: 10867} > 2009-09-06 14:19:25,943 [INFO] koji.build.TaskManager: Task 7 (pid 10867) exited with status 0 > 2009-09-06 14:19:25,973 [INFO] koji.build.TaskManager: Expiring subsession 26 (task 7) > > I also saw kojira log, but I can't find the what problem is. > > 2009-09-06 13:09:23,652 [INFO] koji.repo.manager: Found repo 24, state=INIT > 2009-09-06 13:10:07,760 [INFO] koji.repo.manager: Problem: newRepo task 116 for tag 2 is FAILED > 2009-09-06 13:12:19,724 [INFO] koji.repo.manager: Created newRepo task 121 for tag 2 (dist-foo-build) > 2009-09-06 13:12:25,373 [INFO] koji.repo.manager: Found repo 25, state=INIT > 2009-09-06 13:12:32,349 [INFO] koji.repo.manager: Problem: newRepo task 121 for tag 2 is FAILED > 2009-09-06 14:07:52,959 [INFO] koji: Entering main loop > 2009-09-06 14:14:26,191 [INFO] koji.repo.manager: Created newRepo task 1 for tag 2 (dist-foo-build) > 2009-09-06 14:14:36,261 [INFO] koji.repo.manager: Found repo 1, state=INIT > 2009-09-06 14:15:06,624 [INFO] koji.repo.manager: Problem: newRepo task 1 for tag 2 is FAILED > 2009-09-06 14:15:06,654 [INFO] koji.repo.manager: Created newRepo task 4 for tag 2 (dist-foo-build) > 2009-09-06 14:15:21,807 [INFO] koji.repo.manager: Problem: newRepo task 4 for tag 2 is FAILED > 2009-09-06 14:15:21,868 [INFO] koji.repo.manager: Found repo 2, state=INIT > 2009-09-06 14:18:24,378 [INFO] koji.repo.manager: Created newRepo task 7 for tag 2 (dist-foo-build) > 2009-09-06 14:18:43,487 [INFO] koji.repo.manager: Found repo 3, state=INIT > 2009-09-06 14:19:11,220 [INFO] koji.repo.manager: Problem: newRepo task 7 for tag 2 is FAILED > 2009-09-06 14:21:41,670 [INFO] koji.repo.manager: Created newRepo task 10 for tag 2 (dist-foo-build) > 2009-09-06 14:22:01,882 [INFO] koji.repo.manager: Found repo 4, state=INIT > 2009-09-06 14:22:17,139 [INFO] koji.repo.manager: Problem: newRepo task 10 for tag 2 is FAILED > > I checked if /tmp/koji/tasks/8/8/repo/repodata exist and this folder is not exist. Do you know this folder would be created by what kind of component and Why it could be created yet? > And when here my tasks > > ID Pri Owner State Arch Name > 1 15 kojira FAILED noarch newRepo [kojibuilder1] > 2 14 kojira FAILED noarch +createrepo [kojibuilder1] > 3 14 kojira FAILED noarch +createrepo [kojibuilder1] > 4 15 kojira FAILED noarch newRepo [kojibuilder1] > 5 14 kojira FAILED noarch +createrepo [kojibuilder1] > 6 14 kojira CANCELED noarch +createrepo [kojibuilder1] > > Do you know why kojira can't create repos and solution to solve it. > > Thanks in advance > > Nguy?n V?n T?n > > --- Ng?y Th? 5, 3/09/09, fedora-buildsys-list-request at redhat.com ?? vi?t: > > T?: fedora-buildsys-list-request at redhat.com > Ch? ??: Fedora-buildsys-list Digest, Vol 55, Issue 2 > ??n: fedora-buildsys-list at redhat.com > Ng?y: Th? N?m, 3 th?ng 9, 2009, 23:00 > > Send Fedora-buildsys-list mailing list submissions to > fedora-buildsys-list at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > or, via email, send a message with subject or body 'help' to > fedora-buildsys-list-request at redhat.com > > You can reach the person managing the list at > fedora-buildsys-list-owner at redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Fedora-buildsys-list digest..." > > > Today's Topics: > > 1. Can't Create repos (NGUYEN VAN TAN) > 2. Re: Can't Create repos (rotru at br.ibm.com) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 3 Sep 2009 04:31:37 -0700 (PDT) > From: NGUYEN VAN TAN > Subject: Can't Create repos > To: fedora-buildsys-list at redhat.com > Message-ID:<532535.63316.qm at web62403.mail.re1.yahoo.com> > Content-Type: text/plain; charset="utf-8" > > I'm trying to construct koji-server on Fedora 10, but I got an error. > Kojira can't create repos. It is always failed when try to create repos. > > 2009-09-03 14:06:44,449 [INFO] koji.repo.manager: Created newRepo task 116 for tag 2 (dist-foo-build) > 2009-09-03 14:07:00,198 [INFO] koji.repo.manager: Found repo 24, state=INIT > 2009-09-03 14:07:16,096 [INFO] koji.repo.manager: Problem: newRepo task 116 for tag 2 is FAILED > 2009-09-03 14:10:00,128 [INFO] koji.repo.manager: Created newRepo task 121 for tag 2 (dist-foo-build) > 2009-09-03 14:10:05,331 [INFO] koji.repo.manager: Problem: newRepo task 121 for tag 2 is FAILED > 2009-09-03 14:10:05,397 [INFO] koji.repo.manager: Found repo 25, state=INIT > [root at localhost kojibuilder1]# tail /var/log/kojira.log > 2009-09-03 14:07:16,096 [INFO] koji.repo.manager: Problem: newRepo task 116 for tag 2 is FAILED > 2009-09-03 14:10:00,128 [INFO] koji.repo.manager: Created newRepo task 121 for tag 2 (dist-foo-build) > 2009-09-03 14:10:05,331 [INFO] koji.repo.manager: Problem: newRepo task 121 for tag 2 is FAILED > 2009-09-03 14:10:05,397 [INFO] koji.repo.manager: Found repo 25, state=INIT > 2009-09-03 14:13:05,745 [INFO] koji.repo.manager: Created newRepo task 128 for tag 2 (dist-foo-build) > 2009-09-03 14:13:21,376 [INFO] koji.repo.manager: Found repo 26, state=INIT > 2009-09-03 14:13:37,095 [INFO] koji.repo.manager: Problem: newRepo task 128 for tag 2 is FAILED > 2009-09-03 14:16:23,676 [INFO] koji.repo.manager: Created newRepo task 133 for tag 2 (dist-foo-build) > 2009-09-03 14:16:39,445 [INFO] koji.repo.manager: Problem: newRepo task 133 for tag 2 is FAILED > 2009-09-03 14:16:39,492 [INFO] koji.repo.manager: Found repo 27, state=INIT > > Anyone got this error? And Could you tell me how to solve it? > > Thanks in advance. > > > Nguy?n V?n T?n > > > Thi?t k? ngay m?t Pingbox ??c ??o cho ri?ng b?n! T?o m?t n?i ?? chat tr?n blog l? chuy?n nh?. http://vn.messenger.yahoo.com/pingbox/ > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: https://www.redhat.com/archives/fedora-buildsys-list/attachments/20090903/12fd41f9/attachment.html > > ------------------------------ > > Message: 2 > Date: Thu, 3 Sep 2009 09:13:51 -0300 > From: rotru at br.ibm.com > Subject: Re: Can't Create repos > To: tannv84 at gmail.com, Discussion of Fedora build system > > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > I have already had this problem. Re-check the repo directory permission > (usually in /mnt/koji) and selinux linux permissions as well. > I have selinux disabled, to avoid problems. > > I may find more usefull information in kojid.log. > > Rodrigo Trujillo > > > > From: > NGUYEN VAN TAN > To: > fedora-buildsys-list at redhat.com > Date: > 03/09/2009 08:29 > Subject: > Can't Create repos > > > > > I'm trying to construct koji-server on Fedora 10, but I got an error. > Kojira can't create repos. It is always failed when try to create repos. > > 2009-09-03 14:06:44,449 [INFO] koji.repo.manager: Created newRepo task 116 > for tag 2 (dist-foo-build) > 2009-09-03 14:07:00,198 [INFO] koji.repo.manager: Found repo 24, > state=INIT > 2009-09-03 14:07:16,096 [INFO] koji.repo.manager: Problem: newRepo task > 116 for tag 2 is FAILED > 2009-09-03 14:10:00,128 [INFO] koji.repo.manager: Created newRepo task 121 > for tag 2 (dist-foo-build) > 2009-09-03 14:10:05,331 [INFO] koji.repo.manager: Problem: newRepo task > 121 for tag 2 is FAILED > 2009-09-03 14:10:05,397 [INFO] koji.repo.manager: Found repo 25, > state=INIT > [root at localhost kojibuilder1]# tail /var/log/kojira.log > 2009-09-03 14:07:16,096 [INFO] koji.repo.manager: Problem: newRepo task > 116 for tag 2 is FAILED > 2009-09-03 14:10:00,128 [INFO] koji.repo.manager: Created newRepo task 121 > for tag 2 (dist-foo-build) > 2009-09-03 14:10:05,331 [INFO] koji.repo.manager: Problem: newRepo task > 121 for tag 2 is FAILED > 2009-09-03 14:10:05,397 [INFO] koji.repo.manager: Found repo 25, > state=INIT > 2009-09-03 14:13:05,745 [INFO] koji.repo.manager: Created newRepo task 128 > for tag 2 (dist-foo-build) > 2009-09-03 14:13:21,376 [INFO] koji.repo.manager: Found repo 26, > state=INIT > 2009-09-03 14:13:37,095 [INFO] koji.repo.manager: Problem: newRepo task > 128 for tag 2 is FAILED > 2009-09-03 14:16:23,676 [INFO] koji.repo.manager: Created newRepo task 133 > for tag 2 (dist-foo-build) > 2009-09-03 14:16:39,445 [INFO] koji.repo.manager: Problem: newRepo task > 133 for tag 2 is FAILED > 2009-09-03 14:16:39,492 [INFO] koji.repo.manager: Found repo 27, > state=INIT > > Anyone got this error? And Could you tell me how to solve it? > > Thanks in advance. > > > Nguy?n V?n T?n > > Yahoo! Mail nay NHANH H?N - Th? ngay!-- > 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: https://www.redhat.com/archives/fedora-buildsys-list/attachments/20090903/6a598143/attachment.html > > ------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > End of Fedora-buildsys-list Digest, Vol 55, Issue 2 > *************************************************** > > > > n? ngh? g? khi ??n ?ng r?a b?t v? gi?t qu?n ?o? Xem m?i ng??i ngh? g? tr?n Yahoo! H?i& ??p. http://vn.answers.yahoo.com > > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From mikem at redhat.com Thu Sep 10 18:53:42 2009 From: mikem at redhat.com (Mike McLean) Date: Thu, 10 Sep 2009 14:53:42 -0400 Subject: Can't Create repos In-Reply-To: <532535.63316.qm@web62403.mail.re1.yahoo.com> References: <532535.63316.qm@web62403.mail.re1.yahoo.com> Message-ID: <4AA94B36.4080500@redhat.com> On 09/03/2009 07:31 AM, NGUYEN VAN TAN wrote: > 2009-09-03 14:16:39,445 [INFO] koji.repo.manager: Problem: newRepo task 133 for tag 2 is FAILED > 2009-09-03 14:16:39,492 [INFO] koji.repo.manager: Found repo 27, state=INIT > > Anyone got this error? And Could you tell me how to solve it? kojira merely creates newRepo tasks, which actually run on the builders. If you want to know what went wrong, you should examine the logs for those failed tasks (including the subtasks). From lijian.gnu at gmail.com Mon Sep 14 01:45:10 2009 From: lijian.gnu at gmail.com (=?GB2312?B?wO69qA==?=) Date: Mon, 14 Sep 2009 09:45:10 +0800 Subject: [Errno 10] No child processes In-Reply-To: <9ef5bdcc0909101923k6c950720xfe03510a81586b3f@mail.gmail.com> References: <9ef5bdcc0909101923k6c950720xfe03510a81586b3f@mail.gmail.com> Message-ID: <426c385a0909131845sae2e371p4b370055831e3356@mail.gmail.com> Hi, xiao li This is very normally error. Maybe some configure is wrong, create a builder, it have configure look like following: ------------------------------------------- [root at builder4-x86 ~]# grep mockdir /etc/kojid/kojid.conf mockdir=/dist/mock [root at builder4-x86 ~]# ll -d /dist/mock/ drwxrwsr-x 6 root mock 4096 09-14 09:31 /dist/mock/ [root at builder4-x86 ~]# grep mock /etc/group mock:x:110:kojibuilder [root at builder4-x86 ~]# grep kojibuilder /etc/passwd kojibuilder:x:101:107::/builddir:/bin/bash [root at builder4-x86 ~]# grep kojibuilder /etc/group mock:x:110:kojibuilder kojibuilder:x:107: ============================= 1. must have kojibuilder user and mock group 2. kojibuilder must have privileges to mockdir a chinese help maybe found on my wiki : http://jianlee.ylinux.org/Computer/%E6%9C%8D%E5%8A%A1%E5%99%A8/koji.html#sec64 2009/9/11 xiao li : > When I build srpm.I met a problem.It shows errno 10 and no child > processes.The log follows, > ?'Traceback (most recent call last):\n? File "/usr/sbin/kojid", line 1275, > in runTask\n??? response = (handler.run(),)\n? File "/usr/sbin/kojid", line > 1351, in run\n??? return self.handler(*self.params,**self.opts)\n? File > "/usr/sbin/kojid", line 2009, in handler\n??? broot.init()\n? File > "/usr/sbin/kojid", line 467, in init\n??? rv = self.mock([\'--init\'])\n > File "/usr/sbin/kojid", line 389, in mock\n??? status = os.waitpid(pid, > os.WNOHANG)\nOSError: [Errno 10] No child processes\n'> > ?Thanks for your help. > -- Jian Lee [ http://jianlee.ylinux.org ] From kanarip at kanarip.com Mon Sep 14 04:03:22 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 14 Sep 2009 06:03:22 +0200 Subject: [Errno 10] No child processes In-Reply-To: <426c385a0909131845sae2e371p4b370055831e3356@mail.gmail.com> References: <9ef5bdcc0909101923k6c950720xfe03510a81586b3f@mail.gmail.com> <426c385a0909131845sae2e371p4b370055831e3356@mail.gmail.com> Message-ID: <4AADC08A.3070305@kanarip.com> On 09/14/2009 03:45 AM, ???? wrote: > Hi, xiao li > > This is very normally error. > FWIW, I have this error on Fedora 11 regularly, too. Kind regards, Jeroen van Meeuwen -kanarip From mailing at franzoni.eu Mon Sep 14 15:50:14 2009 From: mailing at franzoni.eu (Alan Franzoni (mailing)) Date: Mon, 14 Sep 2009 17:50:14 +0200 Subject: mock rpmdb version issue with epel-5-i386 target Message-ID: Hello, I'm trying to setup a mock chroot for usage with the epel-5-i386 target. I had considered mach, which I have already used in the past, but since mock seems newer, better mantained an more integrated with fedora and some other tools which look to me very useful and promising ( Cobbler, Koan, Koji ), I wanted to give it a shot. But? I seem to have an issue with it. I started with a fresh FC11 install, with the updates repo enabled, and installed mock from the repos; version 0.9.17 installed cleanly, and seems to be the latest version. My issue seems related to different rpmdb versions inside and outside the chroot which gets created. Take the following output: It seems the rpmdb of the chroot has been created with an rpm employing a different format ( I can assume it's the 'host' system rpm ), hence leading to a format mismatch which prevents from using rpmdb from inside the chroot. I have tinkered around for a little, but I couldn't find an easy solution (beyond installing everything from outside using mock --install, of course). Hence I've got some questions: Is that an intended behaviour? Is the rpmdb supposed to be converted back to the proper format later on in the deployment process, if using mock for building packages which be used later on in a possibly pre-build system? Alan Franzoni From mailing at franzoni.eu Mon Sep 14 15:54:16 2009 From: mailing at franzoni.eu (Alan Franzoni) Date: Mon, 14 Sep 2009 17:54:16 +0200 Subject: mock rpmdb version issue with epel-5-i386 target In-Reply-To: References: Message-ID: I think I've forgot mock output :-/ [user at cobblerserver mock]$ mock --init -r epel-5-i386 INFO: mock.py version 0.9.17 starting... State Changed: init plugins State Changed: start State Changed: lock buildroot State Changed: clean State Changed: init State Changed: lock buildroot Mock Version: 0.9.17 INFO: Mock Version: 0.9.17 INFO: enabled root cache INFO: enabled yum cache State Changed: cleaning yum metadata INFO: enabled ccache State Changed: running yum State Changed: creating cache [user at cobblerserver mock]$ mock --shell -r epel-5-i386 INFO: mock.py version 0.9.17 starting... State Changed: init plugins State Changed: start State Changed: lock buildroot mock-chroot> rpm -qa rpmdb: /var/lib/rpm/Packages: unsupported hash version: 9 error: cannot open Packages index using db3 - Invalid argument (22) error: cannot open Packages database in /var/lib/rpm mock-chroot> rpm --rebuilddb rpmdb: /var/lib/rpm/Packages: unsupported hash version: 9 error: cannot open Packages index using db3 - Invalid argument (22) mock-chroot> exit From mikem at redhat.com Mon Sep 14 16:26:19 2009 From: mikem at redhat.com (Mike McLean) Date: Mon, 14 Sep 2009 12:26:19 -0400 Subject: mock rpmdb version issue with epel-5-i386 target In-Reply-To: References: Message-ID: <4AAE6EAB.6010509@redhat.com> On 09/14/2009 11:50 AM, Alan Franzoni (mailing) wrote: > It seems the rpmdb of the chroot has been created with an rpm > employing a different format ( I can assume it's the 'host' system rpm > ), hence leading to a format mismatch which prevents from using rpmdb > from inside the chroot. > > I have tinkered around for a little, but I couldn't find an easy > solution (beyond installing everything from outside using mock > --install, of course). Hence I've got some questions: The chroot is created from outside the chroot, and hence uses that version of rpm. Consider that when the process starts, there is no rpm in the chroot to use. Note that mock does make it easy to install things manually in the chroot from the outside. > Is that an intended behaviour? intended may be reaching, but known, expected, unavoidable -- yes > Is the rpmdb supposed to be converted > back to the proper format later on in the deployment process, if using > mock for building packages which be used later on in a possibly > pre-build system? There is no back conversion. I'm not sure how this should affect any deployment process for the resulting builds. The rpmdb in the chroot should generally not be accessed by the build itself. Any such activity in a spec file is unwise and questionable. It is unfortunate that this incompatibility was introduced in rpm, but it was for a good reason -- sha256 sums replaced semi-insecure md5sums. One possibility, if you are only building for epel-5 and earlier, is to use an older version of rpm on the host, perhaps just a stock epel-5 install. You'll be unable to build for Fedora 11+ on such a host, though. From jkeating at redhat.com Mon Sep 14 17:13:01 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Sep 2009 10:13:01 -0700 Subject: mock rpmdb version issue with epel-5-i386 target In-Reply-To: <4AAE6EAB.6010509@redhat.com> References: <4AAE6EAB.6010509@redhat.com> Message-ID: <1252948381.6759.25.camel@localhost.localdomain> On Mon, 2009-09-14 at 12:26 -0400, Mike McLean wrote: > It is unfortunate that this incompatibility was introduced in rpm, but > it was for a good reason -- sha256 sums replaced semi-insecure md5sums. Note that you'll have rpmdb mismatches even when creating an EL5 chroot on EL5, if you create an i386 chroot on an x86_64 host. Just that difference is enough to cause rpmdb mismatches. A work around if you must work within the chroot is to remove the db cache, rm -f /var/lib/rpm/__db* -- 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: 198 bytes Desc: This is a digitally signed message part URL: From mailing at franzoni.eu Mon Sep 14 18:09:26 2009 From: mailing at franzoni.eu (Alan Franzoni) Date: Mon, 14 Sep 2009 20:09:26 +0200 Subject: mock rpmdb version issue with epel-5-i386 target In-Reply-To: <4AAE6EAB.6010509@redhat.com> References: <4AAE6EAB.6010509@redhat.com> Message-ID: 2009/9/14 Mike McLean : > The chroot is created from outside the chroot, and hence uses that version > of rpm. Consider that when the process starts, there is no rpm in the chroot > to use. Yes, I had noticed that. > There is no back conversion. I'm not sure how this should affect any > deployment process for the resulting builds. The rpmdb in the chroot should > generally not be accessed by the build itself. Any such activity in a spec > file is unwise and questionable. Sure it is, and such activity is not performed inside any of any SPEC. I think that maybe I just asked the wrong question. One of my targets is to build SRPMs inside an epel-5-i386 chroot; this can be done pretty easily with mock, but what if I have a dependency on an RPM which is not available in a yum repo? I'd like to test some internally built rpms in a pseudo-production environment *before* they're sent to our repo. So I just wanted to use "--copyin", then use --shell to manually invoke rpm and manually install such packages. Also, sometimes some packages have build dependencies that can't be satisfied by repos and should be installed manually (again, dependency on a test package). If it's the quickest path I'll just setup an internal, testing only, can-be-trashed-at-any-time repository, possibly on the vary same machine hosting mock. Then I'll also need to build "full" images for some machines to deploy (e.g. a gzipped tar which holds the full operating system along with some rpms) in our testing environment, but I suppose I can use cobbler/koan for that, and I imagine they work differently and support a working rpm inside? -- Alan Franzoni -- contact me at public@[mysurname].eu From paul.schroeder at bluecoat.com Mon Sep 14 18:29:37 2009 From: paul.schroeder at bluecoat.com (Paul B Schroeder) Date: Mon, 14 Sep 2009 13:29:37 -0500 Subject: mock rpmdb version issue with epel-5-i386 target In-Reply-To: <1252948381.6759.25.camel@localhost.localdomain> References: <4AAE6EAB.6010509@redhat.com> <1252948381.6759.25.camel@localhost.localdomain> Message-ID: <4AAE8B91.9040909@bluecoat.com> On 09/14/2009 12:13 PM, Jesse Keating wrote: > On Mon, 2009-09-14 at 12:26 -0400, Mike McLean wrote: >> It is unfortunate that this incompatibility was introduced in rpm, but >> it was for a good reason -- sha256 sums replaced semi-insecure md5sums. > > Note that you'll have rpmdb mismatches even when creating an EL5 chroot > on EL5, if you create an i386 chroot on an x86_64 host. Just that > difference is enough to cause rpmdb mismatches. A work around if you > must work within the chroot is to remove the db cache, rm > -f /var/lib/rpm/__db* With F11, I have found that I also had to remove /var/lib/rpm/Packages when doing anything in an EL5 chroot that mucks with the rpmdb. e.g. Building ISOs with Revisor. (My Makefile also does '/bin/rpm --rebuilddb' before executing Revisor) -- --- Paul B Schroeder Blue Coat Systems, Inc. From mikem at redhat.com Mon Sep 14 18:38:25 2009 From: mikem at redhat.com (Mike McLean) Date: Mon, 14 Sep 2009 14:38:25 -0400 Subject: mock rpmdb version issue with epel-5-i386 target In-Reply-To: References: <4AAE6EAB.6010509@redhat.com> Message-ID: <4AAE8DA1.2070006@redhat.com> On 09/14/2009 02:09 PM, Alan Franzoni wrote: >> There is no back conversion. I'm not sure how this should affect any >> deployment process for the resulting builds. The rpmdb in the chroot should >> generally not be accessed by the build itself. Any such activity in a spec >> file is unwise and questionable. > > Sure it is, and such activity is not performed inside any of any SPEC. Sorry, was just guessing. I have seen folks try to read the rpmdb at build time before. > One of my targets is to build SRPMs inside an epel-5-i386 chroot; this > can be done pretty easily with mock, but what if I have a dependency > on an RPM which is not available in a yum repo? I'd like to test some > internally built rpms in a pseudo-production environment *before* > they're sent to our repo. So I just wanted to use "--copyin", then use > --shell to manually invoke rpm and manually install such packages. > Also, sometimes some packages have build dependencies that can't be > satisfied by repos and should be installed manually (again, dependency > on a test package). You could just use the rpm command line with --root to install from outside the chroot. If you want to make sure all the mounts that mock creates are in place, the easiest way is to use mock --shell in one window, leave that idle, and run the rpm --root (or perhaps yum --installroot $d localinstall $f) command in another window (outside the chroot). Hackish, but, functional. I suppose we should add a way to access the yum localinstall functionality through mock. > If it's the quickest path I'll just setup an internal, testing only, > can-be-trashed-at-any-time repository, possibly on the vary same > machine hosting mock. That may be easier if you do this often. I'm sure you're aware, but just for completeness note that you can include more than one repo in the mock config, allowing this testing repo to be a small add-on (and hence a very quick run of createrepo). From dennis at ausil.us Mon Sep 14 18:43:53 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 14 Sep 2009 13:43:53 -0500 Subject: mock rpmdb version issue with epel-5-i386 target In-Reply-To: References: <4AAE6EAB.6010509@redhat.com> Message-ID: <200909141343.58029.dennis@ausil.us> On Monday 14 September 2009 01:09:26 pm Alan Franzoni wrote: > 2009/9/14 Mike McLean : > > The chroot is created from outside the chroot, and hence uses that > > version of rpm. Consider that when the process starts, there is no rpm in > > the chroot to use. > > Yes, I had noticed that. > > > There is no back conversion. I'm not sure how this should affect any > > deployment process for the resulting builds. The rpmdb in the chroot > > should generally not be accessed by the build itself. Any such activity > > in a spec file is unwise and questionable. > > Sure it is, and such activity is not performed inside any of any SPEC. > > I think that maybe I just asked the wrong question. > > One of my targets is to build SRPMs inside an epel-5-i386 chroot; this > can be done pretty easily with mock, but what if I have a dependency > on an RPM which is not available in a yum repo? I'd like to test some > internally built rpms in a pseudo-production environment *before* > they're sent to our repo. So I just wanted to use "--copyin", then use > --shell to manually invoke rpm and manually install such packages. > Also, sometimes some packages have build dependencies that can't be > satisfied by repos and should be installed manually (again, dependency > on a test package). build your srpm with --nodeps that way you dont need the buildrequires packages installed to make your srpm. this is how koji does it. > > If it's the quickest path I'll just setup an internal, testing only, > can-be-trashed-at-any-time repository, possibly on the vary same > machine hosting mock. setup a local repo. is the easiest way. > Then I'll also need to build "full" images for some machines to deploy > (e.g. a gzipped tar which holds the full operating system along with > some rpms) in our testing environment, but I suppose I can use > cobbler/koan for that, and I imagine they work differently and support > a working rpm inside? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mikem at redhat.com Mon Sep 14 18:51:56 2009 From: mikem at redhat.com (Mike McLean) Date: Mon, 14 Sep 2009 14:51:56 -0400 Subject: mock rpmdb version issue with epel-5-i386 target In-Reply-To: <1252948381.6759.25.camel@localhost.localdomain> References: <4AAE6EAB.6010509@redhat.com> <1252948381.6759.25.camel@localhost.localdomain> Message-ID: <4AAE90CC.2070408@redhat.com> On 09/14/2009 01:13 PM, Jesse Keating wrote: > Note that you'll have rpmdb mismatches even when creating an EL5 chroot > on EL5, if you create an i386 chroot on an x86_64 host. Just that > difference is enough to cause rpmdb mismatches. A work around if you > must work within the chroot is to remove the db cache, rm > -f /var/lib/rpm/__db* Of course, that is a smaller level of incompatibility since those files are so safely removable (as long as there is not a transaction running). I've encountered many issues with one version not liking another version's __db files over the years, but this is the first time since RHL6.2 that I recall the main database files being incompatible like this. From tibbs at math.uh.edu Mon Sep 14 21:13:32 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 14 Sep 2009 16:13:32 -0500 Subject: mock rpmdb version issue with epel-5-i386 target In-Reply-To: <4AAE8DA1.2070006@redhat.com> (Mike McLean's message of "Mon, 14 Sep 2009 14:38:25 -0400") References: <4AAE6EAB.6010509@redhat.com> <4AAE8DA1.2070006@redhat.com> Message-ID: >>>>> "MM" == Mike McLean writes: MM> I suppose we should add a way to access the yum localinstall MM> functionality through mock. I have done this for years: echo Installing built packages: runmock -v --install $MOCKDIR/result/*{i386,x86_64,noarch}.rpm 2>&1 (dependent on the rest of the script, of course, but you get the idea). - J< From mikem at redhat.com Tue Sep 15 14:31:09 2009 From: mikem at redhat.com (Mike McLean) Date: Tue, 15 Sep 2009 10:31:09 -0400 Subject: mock rpmdb version issue with epel-5-i386 target In-Reply-To: References: <4AAE6EAB.6010509@redhat.com> <4AAE8DA1.2070006@redhat.com> Message-ID: <4AAFA52D.2000203@redhat.com> On 09/14/2009 05:13 PM, Jason L Tibbitts III wrote: > MM> I suppose we should add a way to access the yum localinstall > MM> functionality through mock. > > I have done this for years: > > echo Installing built packages: > runmock -v --install $MOCKDIR/result/*{i386,x86_64,noarch}.rpm 2>&1 > > (dependent on the rest of the script, of course, but you get the idea). Ah, apparently yum now (and perhaps for a while) handles local rpms via the install command as well as the localinstall command. Hence, you can access this functionality via mock. At one point, yum did not do this and you had to use localinstall for local rpms. Good to know. Thanks :) From skvidal at fedoraproject.org Tue Sep 15 14:35:04 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 15 Sep 2009 10:35:04 -0400 (EDT) Subject: mock rpmdb version issue with epel-5-i386 target In-Reply-To: <4AAFA52D.2000203@redhat.com> References: <4AAE6EAB.6010509@redhat.com> <4AAE8DA1.2070006@redhat.com> <4AAFA52D.2000203@redhat.com> Message-ID: On Tue, 15 Sep 2009, Mike McLean wrote: > On 09/14/2009 05:13 PM, Jason L Tibbitts III wrote: >> MM> I suppose we should add a way to access the yum localinstall >> MM> functionality through mock. >> >> I have done this for years: >> >> echo Installing built packages: >> runmock -v --install $MOCKDIR/result/*{i386,x86_64,noarch}.rpm 2>&1 >> >> (dependent on the rest of the script, of course, but you get the idea). > > Ah, apparently yum now (and perhaps for a while) handles local rpms via the > install command as well as the localinstall command. Hence, you can access > this functionality via mock. > > At one point, yum did not do this and you had to use localinstall for local > rpms. > > Good to know. Thanks :) localinstalls still care about gpgsignatures, though - so you make sure you have the right keys or turn off gpg checking. -sv From mailing at franzoni.eu Tue Sep 15 14:36:59 2009 From: mailing at franzoni.eu (Alan Franzoni) Date: Tue, 15 Sep 2009 16:36:59 +0200 Subject: mock rpmdb version issue with epel-5-i386 target In-Reply-To: <4AAFA52D.2000203@redhat.com> References: <4AAE6EAB.6010509@redhat.com> <4AAE8DA1.2070006@redhat.com> <4AAFA52D.2000203@redhat.com> Message-ID: 2009/9/15 Mike McLean : [cut] I think I got all the info I need, and I wish to thank you all for your excellent and prompt support! -- Alan Franzoni -- contact me at public@[mysurname].eu From notting at redhat.com Tue Sep 15 15:22:03 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 15 Sep 2009 11:22:03 -0400 Subject: [PATCH] pungi: Fix dependency resolution to recurse properly. Message-ID: <20090915152203.GA27012@nostromo.devel.redhat.com> It wasn't properly recusing in the --selfhosting or --fulltree cases before, leading to potenial broken deps. Bill Signed-off-by: Bill Nottingham --- src/pypungi/__init__.py | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/src/pypungi/__init__.py b/src/pypungi/__init__.py index 26c8bdf..aec3c8c 100644 --- a/src/pypungi/__init__.py +++ b/src/pypungi/__init__.py @@ -255,6 +255,7 @@ class Pungi(pypungi.PungiBase): reqs = po.requires provs = po.provides + added = [] for req in reqs: if self.resolved_deps.has_key(req): @@ -275,8 +276,10 @@ class Pungi(pypungi.PungiBase): for dep in depsack.returnNewestByNameArch(): self.ayum.tsInfo.addInstall(dep) self.logger.info('Added %s.%s for %s.%s' % (dep.name, dep.arch, po.name, po.arch)) - + added.append(dep) self.resolved_deps[req] = None + for add in added: + self.getPackageDeps(add) def getPackagesFromGroup(self, group): """Get a list of package names from a ksparser group object @@ -483,6 +486,7 @@ class Pungi(pypungi.PungiBase): for txmbr in self.ayum.tsInfo: if txmbr.po.arch != 'src' and txmbr.po not in self.polist: self.polist.append(txmbr.po) + self.getPackageDeps(txmbr.po) self.srpms_build = list(self.srpmpolist) # Now that we've resolved deps, refresh the source rpm list self.getSRPMList() @@ -508,6 +512,7 @@ class Pungi(pypungi.PungiBase): for txmbr in self.ayum.tsInfo: if txmbr.po.arch != 'src' and txmbr.po not in self.polist: self.polist.append(txmbr.po) + self.getPackageDeps(po) self.srpms_fulltree = list(self.srpmpolist) # Now that we've resolved deps, refresh the source rpm list self.getSRPMList() -- 1.6.4.3 From dgregor at redhat.com Tue Sep 15 15:42:37 2009 From: dgregor at redhat.com (Dennis Gregorovic) Date: Tue, 15 Sep 2009 11:42:37 -0400 Subject: [PATCH] pungi: Fix dependency resolution to recurse properly. In-Reply-To: <20090915152203.GA27012@nostromo.devel.redhat.com> References: <20090915152203.GA27012@nostromo.devel.redhat.com> Message-ID: <1253029357.4171.141.camel@localhost.localdomain> On Tue, 2009-09-15 at 11:22 -0400, Bill Nottingham wrote: > It wasn't properly recusing in the --selfhosting or --fulltree cases > before, leading to potenial broken deps. > > Bill Interesting. I just noticed this morning that there were more broken deps in the tree than in the build roots, which didn't make sense. I'll give this patch a try and see if that fixes it. Cheers -- Dennis From jkeating at redhat.com Tue Sep 15 22:12:05 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Sep 2009 15:12:05 -0700 Subject: [PATCH] pungi: Fix dependency resolution to recurse properly. In-Reply-To: <20090915152203.GA27012@nostromo.devel.redhat.com> References: <20090915152203.GA27012@nostromo.devel.redhat.com> Message-ID: <1253052725.32695.15.camel@localhost.localdomain> On Tue, 2009-09-15 at 11:22 -0400, Bill Nottingham wrote: > It wasn't properly recusing in the --selfhosting or --fulltree cases > before, leading to potenial broken deps. > > Applied and built on rawhide. -- 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: 198 bytes Desc: This is a digitally signed message part URL: From pmatilai at laiskiainen.org Wed Sep 16 07:40:35 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 16 Sep 2009 10:40:35 +0300 (EEST) Subject: mock rpmdb version issue with epel-5-i386 target In-Reply-To: <4AAE6EAB.6010509@redhat.com> References: <4AAE6EAB.6010509@redhat.com> Message-ID: On Mon, 14 Sep 2009, Mike McLean wrote: > On 09/14/2009 11:50 AM, Alan Franzoni (mailing) wrote: >> It seems the rpmdb of the chroot has been created with an rpm >> employing a different format ( I can assume it's the 'host' system rpm >> ), hence leading to a format mismatch which prevents from using rpmdb >> from inside the chroot. >> >> I have tinkered around for a little, but I couldn't find an easy >> solution (beyond installing everything from outside using mock >> --install, of course). Hence I've got some questions: > > The chroot is created from outside the chroot, and hence uses that version of > rpm. Consider that when the process starts, there is no rpm in the chroot to > use. > > Note that mock does make it easy to install things manually in the chroot > from the outside. > >> Is that an intended behaviour? > > intended may be reaching, but known, expected, unavoidable -- yes > >> Is the rpmdb supposed to be converted >> back to the proper format later on in the deployment process, if using >> mock for building packages which be used later on in a possibly >> pre-build system? > > There is no back conversion. I'm not sure how this should affect any > deployment process for the resulting builds. The rpmdb in the chroot should > generally not be accessed by the build itself. Any such activity in a spec > file is unwise and questionable. > > It is unfortunate that this incompatibility was introduced in rpm, but it was > for a good reason -- sha256 sums replaced semi-insecure md5sums. Mind you, the error here has nothing to do with sha256/md5: rpmdb: /var/lib/rpm/Packages: unsupported hash version: 9 error: cannot open Packages index using db3 - Invalid argument (22) error: cannot open Packages database in /var/lib/rpm This is a much lower level thing, a Berkeley DB internal format incompatibility: BDB can always read (up to a point) databases created with older versions, but there's no guarantee the other way around. For example BDB 4.3 and 4.5 were interchangably compatible but BDB 4.7 (which is what RPM in Fedora 11 uses) is not. The rpm-level view of the database hasn't really changed since the very beginning - it's just a pile of header binary blobs and some associated indexes. It is in fact possible to manually downgrade the database to and older BDB format by using db_dump and db_load of appropriate BDB versions, it's just not something that can be automatically done by RPM. So while not exactly practical, you can install say RHEL 5 package set with Fedora 11 RPM, manually downgrade the BDB format to RHEL 5 RPM's level with BDB tools, do rpm --rebuilddb with the RHEL 5 rpm to recreate indexes and voila, you have fully "converted the db for later deployment". And then there's the third level of compatibility: the data contained within headers and it's interpretation. The md5 vs sha256 (or actually, the algorithm is configurable) is just interpretation of tag values, the data types of these are recognizable and accessible by pretty much any old RPM you can dig up, but those older rpm versions wouldn't know what to do with this tag even though they can load such a header. A more fundamental issue is header data types unknown to older versions: RPM 4.6 introduced 64bit integer type, and headers containing such data cannot be even loaded by older RPM versions as internal consistency checks cause failure on unknown data types. Because this is such a grave incompatibility, RPM avoids using 64bit types in headers when they're strictly not needed, ie if 32bit integer is sufficient to contain the package/file sizes. To my knowledge, there are no > 4GB packages in Fedora so this is not an issue so far. - Panu - From jwboyer at gmail.com Fri Sep 18 01:25:33 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 17 Sep 2009 21:25:33 -0400 Subject: ascii mergerepo error in local koji instance Message-ID: <625fc13d0909171825q275a850bg67e11ce43dfd7dc4@mail.gmail.com> I'm seeing this error when trying to do a newRepo task on my local koji server, using rawhide as an external repo: 2101/14674 - python-decoratortools-1.7-4.fc12.noarch 2102/14674 - ruby-atk-0.19.1-2.fc12.ppc 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.6/site-packages/createrepo/__init__.py", line 364, in doPkgMetadata self.writeMetadataDocs(packages) File "/usr/lib/python2.6/site-packages/createrepo/__init__.py", line 527, in writeMetadataDocs self.primaryfile.write(po.xml_dump_primary_metadata()) File "/usr/lib/python2.6/site-packages/yum/packages.py", line 1015, in xml_dump_primary_metadata msg += misc.to_unicode(self._dump_format_items()) File "/usr/lib/python2.6/site-packages/yum/packages.py", line 894, in _dump_format_items msg += self._dump_pco('provides') File "/usr/lib/python2.6/site-packages/yum/packages.py", line 919, in _dump_pco msg += pcostring UnicodeDecodeError: 'ascii' codec can't decode byte 0xec in position 28: ordinal not in range(128) [root at koji 97]# The builders and hub are all running a fully updated F11. This is the first newRepo task after the repo addition, so it's all purely from rawhide. I see that there was a similar report of this in the past, but I don't see a resolution? Is there a patch I need to apply, or do I have to block the erroring packages in koji, or? Help would be appreciated. (I'm also confused why the main koji instance isn't hitting this). josh From kanarip at kanarip.com Fri Sep 18 08:28:37 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 18 Sep 2009 10:28:37 +0200 Subject: ascii mergerepo error in local koji instance In-Reply-To: <625fc13d0909171825q275a850bg67e11ce43dfd7dc4@mail.gmail.com> References: <625fc13d0909171825q275a850bg67e11ce43dfd7dc4@mail.gmail.com> Message-ID: <4AB344B5.8030109@kanarip.com> On 09/18/2009 03:25 AM, Josh Boyer wrote: > I'm seeing this error when trying to do a newRepo task on my local > koji server, using rawhide as an external repo: > I've seen the exact same thing over and over again. I logged https://bugzilla.redhat.com/show_bug.cgi?id=495735 for this. The main koji instance isn't hitting this because it doesn't use mergerepos against repos that have the latest nifty auto-font-provides in them, I think. Kind regards, Jeroen van Meeuwen -kanarip From jwboyer at gmail.com Fri Sep 18 10:33:51 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 18 Sep 2009 06:33:51 -0400 Subject: ascii mergerepo error in local koji instance In-Reply-To: <4AB344B5.8030109@kanarip.com> References: <625fc13d0909171825q275a850bg67e11ce43dfd7dc4@mail.gmail.com> <4AB344B5.8030109@kanarip.com> Message-ID: <20090918103351.GB4536@hansolo.jdub.homelinux.org> On Fri, Sep 18, 2009 at 10:28:37AM +0200, Jeroen van Meeuwen wrote: > On 09/18/2009 03:25 AM, Josh Boyer wrote: >> I'm seeing this error when trying to do a newRepo task on my local >> koji server, using rawhide as an external repo: >> > > I've seen the exact same thing over and over again. I logged > https://bugzilla.redhat.com/show_bug.cgi?id=495735 for this. Thanks. > The main koji instance isn't hitting this because it doesn't use > mergerepos against repos that have the latest nifty auto-font-provides > in them, I think. Having trouble parsing that. I'm using rawhide packges. How is the main koji not using mergerepos there? If it's not, is there some config switch I need to flip or something like that? josh From kanarip at kanarip.com Sat Sep 19 14:32:17 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 19 Sep 2009 16:32:17 +0200 Subject: ascii mergerepo error in local koji instance In-Reply-To: <20090918103351.GB4536@hansolo.jdub.homelinux.org> References: <625fc13d0909171825q275a850bg67e11ce43dfd7dc4@mail.gmail.com> <4AB344B5.8030109@kanarip.com> <20090918103351.GB4536@hansolo.jdub.homelinux.org> Message-ID: <4AB4EB71.90606@kanarip.com> On 09/18/2009 12:33 PM, Josh Boyer wrote: > On Fri, Sep 18, 2009 at 10:28:37AM +0200, Jeroen van Meeuwen wrote: >> On 09/18/2009 03:25 AM, Josh Boyer wrote: >>> I'm seeing this error when trying to do a newRepo task on my local >>> koji server, using rawhide as an external repo: >>> >> >> I've seen the exact same thing over and over again. I logged >> https://bugzilla.redhat.com/show_bug.cgi?id=495735 for this. > > Thanks. > >> The main koji instance isn't hitting this because it doesn't use >> mergerepos against repos that have the latest nifty auto-font-provides >> in them, I think. > > Having trouble parsing that. I'm using rawhide packges. How is the main > koji not using mergerepos there? If it's not, is there some config switch > I need to flip or something like that? > Mergerepos is only used for external repository support, not for repositories internal to koji. The only build-targets in the main koji instance that use mergerepos are the epel build-targets. mergerepos or yum.packages does not have a problem with these packages, but it does have a problem with packages (apparently) that provide font(lang=some), where "some" is characters I don't know what they are. My blocked packages now include: 3 apanov-edrip-fonts 4 apanov-heuristica-fonts 5 baekmuk-ttf-fonts 6 hanazono-fonts 13 ipa-gothic-fonts 7 ipa-mincho-fonts 8 ipa-pgothic-fonts 9 ipa-pmincho-fonts 10 sazanami-fonts 16 un-core-fonts 15 un-core-gungseo-fonts 11 vlgothic-fonts 12 wqy-zenhei-fonts And so they are not causing mergerepos to traceback anymore. -- Jeroen From thatch45 at gmail.com Wed Sep 23 20:24:33 2009 From: thatch45 at gmail.com (Thomas S Hatch) Date: Wed, 23 Sep 2009 14:24:33 -0600 Subject: Pungi exact package version Message-ID: <6172c17e0909231324m4d1a4c05xdaf485f4a0e85ed9@mail.gmail.com> I am building an auto install iso for some repeated, specialized deployments and I have run into a problem. I am building them with pungi and using the latest packages from fedora 11, but a bug in the 2.6.30 kernel seems to be preventing me from installing from cdrom. Anaconda fails to find the cdrom drive on the hardware I am using (IBM hs22 bladecenter). The problem is fixed by using a 2.6.29 kernel. So I was hoping that I could build my installer iso with pungi, and the updates repository, but exclude the latest kernel so a 2.6.29 kernel is used. Is this possible without maintaining a modified local copy of the updates repository? -Tom Hatch -------------- next part -------------- An HTML attachment was scrubbed... URL: From kanarip at kanarip.com Sat Sep 26 21:26:22 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 26 Sep 2009 23:26:22 +0200 Subject: Pungi exact package version In-Reply-To: <6172c17e0909231324m4d1a4c05xdaf485f4a0e85ed9@mail.gmail.com> References: <6172c17e0909231324m4d1a4c05xdaf485f4a0e85ed9@mail.gmail.com> Message-ID: <4ABE86FE.6090803@kanarip.com> On 09/23/2009 10:24 PM, Thomas S Hatch wrote: > I am building an auto install iso for some repeated, specialized > deployments and I have run into a problem. I am building them with > pungi and using the latest packages from fedora 11, but a bug in the > 2.6.30 kernel seems to be preventing me from installing from cdrom. > Anaconda fails to find the cdrom drive on the hardware I am using (IBM > hs22 bladecenter). The problem is fixed by using a 2.6.29 kernel. So I > was hoping that I could build my installer iso with pungi, and the > updates repository, but exclude the latest kernel so a 2.6.29 kernel is > used. Is this possible without maintaining a modified local copy of the > updates repository? > Pungi does not support selecting exact package nevra in the %packages manifest of a kickstart, but Revisor does; use --kickstart-nevra -- Jeroen From julian.fedoralists at googlemail.com Sat Sep 26 21:47:47 2009 From: julian.fedoralists at googlemail.com (Julian Aloofi) Date: Sat, 26 Sep 2009 23:47:47 +0200 Subject: Pungi exact package version In-Reply-To: <4ABE86FE.6090803@kanarip.com> References: <6172c17e0909231324m4d1a4c05xdaf485f4a0e85ed9@mail.gmail.com> <4ABE86FE.6090803@kanarip.com> Message-ID: <1254001667.2724.4.camel@Julians-Notebook> Am Samstag, den 26.09.2009, 23:26 +0200 schrieb Jeroen van Meeuwen: > Pungi does not support selecting exact package nevra in the %packages > manifest of a kickstart, but Revisor does; use --kickstart-nevra > > -- Jeroen I guess you mean --kickstart-exact-nevra, or is this equivalent? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From thatch45 at gmail.com Sat Sep 26 23:57:46 2009 From: thatch45 at gmail.com (Thomas S Hatch) Date: Sat, 26 Sep 2009 17:57:46 -0600 Subject: Pungi exact package version In-Reply-To: <1254001667.2724.4.camel@Julians-Notebook> References: <6172c17e0909231324m4d1a4c05xdaf485f4a0e85ed9@mail.gmail.com> <4ABE86FE.6090803@kanarip.com> <1254001667.2724.4.camel@Julians-Notebook> Message-ID: <6172c17e0909261657h16f715ev1576837a4c174170@mail.gmail.com> Thanks, I found another workaround for now, but if it comes up again I will look into revisor. On Sat, Sep 26, 2009 at 3:47 PM, Julian Aloofi < julian.fedoralists at googlemail.com> wrote: > Am Samstag, den 26.09.2009, 23:26 +0200 schrieb Jeroen van Meeuwen: > > Pungi does not support selecting exact package nevra in the %packages > > manifest of a kickstart, but Revisor does; use --kickstart-nevra > > > > -- Jeroen > > I guess you mean --kickstart-exact-nevra, or is this equivalent? > > -- > 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 kanarip at kanarip.com Sun Sep 27 13:44:24 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 27 Sep 2009 15:44:24 +0200 Subject: Pungi exact package version In-Reply-To: <1254001667.2724.4.camel@Julians-Notebook> References: <6172c17e0909231324m4d1a4c05xdaf485f4a0e85ed9@mail.gmail.com> <4ABE86FE.6090803@kanarip.com> <1254001667.2724.4.camel@Julians-Notebook> Message-ID: <4ABF6C38.4000706@kanarip.com> On 09/26/2009 11:47 PM, Julian Aloofi wrote: > Am Samstag, den 26.09.2009, 23:26 +0200 schrieb Jeroen van Meeuwen: >> Pungi does not support selecting exact package nevra in the %packages >> manifest of a kickstart, but Revisor does; use --kickstart-nevra >> > > I guess you mean --kickstart-exact-nevra, or is this equivalent? > Oops, yes, I mean --kickstart-exact-nevra. -- Jeroen From jwboyer at gmail.com Mon Sep 28 16:39:35 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 28 Sep 2009 12:39:35 -0400 Subject: Adding builders without NFS access Message-ID: <20090928163935.GI5260@hansolo.jdub.homelinux.org> Hi All, I believe that currently any koji builder needs to have read-only access to /mnt/koji, normally realized by NFS mounting. I am wondering if there is a way to add builders to a koji instance without requiring this. In my thinking, this essentially means that all builders must be colocated in the same lab. That is a bit unfortunate, given that adding builders outside of the local lab is one of the things that could really help a secondary arch. Has any work gone into not requiring /mnt/koji to the builders? Thanks, josh From dan at danny.cz Mon Sep 28 16:59:12 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Mon, 28 Sep 2009 18:59:12 +0200 Subject: Adding builders without NFS access In-Reply-To: <20090928163935.GI5260@hansolo.jdub.homelinux.org> References: <20090928163935.GI5260@hansolo.jdub.homelinux.org> Message-ID: <1254157152.3799.71.camel@eagle.danny.cz> Josh Boyer p??e v Po 28. 09. 2009 v 12:39 -0400: > Hi All, > > I believe that currently any koji builder needs to have read-only access to > /mnt/koji, normally realized by NFS mounting. I am wondering if there is a > way to add builders to a koji instance without requiring this. Only HTTP connection is required between the hub and the builders. That's how we have it set up for Fedora/s390x. > In my thinking, this essentially means that all builders must be colocated in > the same lab. That is a bit unfortunate, given that adding builders outside > of the local lab is one of the things that could really help a secondary arch. > > Has any work gone into not requiring /mnt/koji to the builders? Dan From jkeating at j2solutions.net Mon Sep 28 17:01:24 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 28 Sep 2009 10:01:24 -0700 Subject: Adding builders without NFS access In-Reply-To: <20090928163935.GI5260@hansolo.jdub.homelinux.org> References: <20090928163935.GI5260@hansolo.jdub.homelinux.org> Message-ID: <5CFDC455-CD7C-4C88-B230-A57424334905@j2solutions.net> On Sep 28, 2009, at 9:39, Josh Boyer wrote: > Hi All, > > I believe that currently any koji builder needs to have read-only > access to > /mnt/koji, normally realized by NFS mounting. I am wondering if > there is a > way to add builders to a koji instance without requiring this. > > In my thinking, this essentially means that all builders must be > colocated in > the same lab. That is a bit unfortunate, given that adding builders > outside > of the local lab is one of the things that could really help a > secondary arch. > > Has any work gone into not requiring /mnt/koji to the builders? > > Thanks, > josh > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list Should be fine if you take them out of the createrepo channel -- Jes From jwboyer at gmail.com Mon Sep 28 18:00:54 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 28 Sep 2009 14:00:54 -0400 Subject: Adding builders without NFS access In-Reply-To: <5CFDC455-CD7C-4C88-B230-A57424334905@j2solutions.net> References: <20090928163935.GI5260@hansolo.jdub.homelinux.org> <5CFDC455-CD7C-4C88-B230-A57424334905@j2solutions.net> Message-ID: <20090928180054.GJ5260@hansolo.jdub.homelinux.org> On Mon, Sep 28, 2009 at 10:01:24AM -0700, Jesse Keating wrote: > > > On Sep 28, 2009, at 9:39, Josh Boyer wrote: > >> Hi All, >> >> I believe that currently any koji builder needs to have read-only >> access to >> /mnt/koji, normally realized by NFS mounting. I am wondering if there >> is a >> way to add builders to a koji instance without requiring this. >> >> In my thinking, this essentially means that all builders must be >> colocated in >> the same lab. That is a bit unfortunate, given that adding builders >> outside >> of the local lab is one of the things that could really help a >> secondary arch. >> >> Has any work gone into not requiring /mnt/koji to the builders? >> >> Thanks, >> josh >> >> -- >> Fedora-buildsys-list mailing list >> Fedora-buildsys-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > Should be fine if you take them out of the createrepo channel OK, I might have misunderstood then. It just so happens that my builders are the only creatrepo enabled hosts. I find that to be good news. josh From mikem at redhat.com Mon Sep 28 19:11:49 2009 From: mikem at redhat.com (Mike McLean) Date: Mon, 28 Sep 2009 15:11:49 -0400 Subject: Adding builders without NFS access In-Reply-To: <20090928163935.GI5260@hansolo.jdub.homelinux.org> References: <20090928163935.GI5260@hansolo.jdub.homelinux.org> Message-ID: <4AC10A75.4030206@redhat.com> On 09/28/2009 12:39 PM, Josh Boyer wrote: > I believe that currently any koji builder needs to have read-only access to > /mnt/koji, normally realized by NFS mounting. I am wondering if there is a > way to add builders to a koji instance without requiring this. This is entirely possible and has been in place for years I think. As Jesse points out, you need to make sure any builders that lack the nfs mount are not in the createrepo channel. Also, you need to make sure you have the builders configured for http access. That means you need to set topurl instead of topdir in the config as well as setting the pkgurl option. Of course that means your kojidir must be http accessible from somewhere. I should also point out that the shared fs need not be accomplished by nfs (though this is arguably the easiest method). There are multiple ways of sharing a filesystem across machines. From steve.traylen at cern.ch Wed Sep 30 08:05:48 2009 From: steve.traylen at cern.ch (Steve Traylen) Date: Wed, 30 Sep 2009 10:05:48 +0200 Subject: latest python-cheetah breaks koji. Message-ID: Hi, I would just submit a bug but unsure to which package to submit in the first instance. On FC11 with Hi With, koji-hub-1.3.1-2.fc11.noarch koji-1.3.1-2.fc11.noarch koji-builder-1.3.1-2.fc11.noarch koji-web-1.3.1-2.fc11.noarch koji-utils-1.3.1-2.fc11.noarch python-cheetah-2.0.1-5.fc11.x86_64 then everything is good. Updating only python-cheetah to python-cheetah-2.2.2-1.fc11.x86_64 then python-web dumps to the browser as below, full traceback attached. Downgrading back to python-cheetah-2.0.1-5.fc11.x86_64 then all is good. File "/usr/lib64/python2.6/site-packages/Cheetah/Compiler.py", line 1588, in __init__ source = unicode(source) UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 374: ordinal not in range(128) full back trace attached. Steve -- Steve Traylen From mikeb at redhat.com Wed Sep 30 21:08:51 2009 From: mikeb at redhat.com (Mike Bonnet) Date: Wed, 30 Sep 2009 17:08:51 -0400 Subject: latest python-cheetah breaks koji. In-Reply-To: References: Message-ID: <4AC3C8E3.3030104@redhat.com> On 09/30/2009 04:05 AM, Steve Traylen wrote: > Hi, > I would just submit a bug but unsure to which package to submit in > the first instance. > > On FC11 with > Hi > > With, > > koji-hub-1.3.1-2.fc11.noarch > koji-1.3.1-2.fc11.noarch > koji-builder-1.3.1-2.fc11.noarch > koji-web-1.3.1-2.fc11.noarch > koji-utils-1.3.1-2.fc11.noarch > python-cheetah-2.0.1-5.fc11.x86_64 > > then everything is good. > > Updating only python-cheetah to > > python-cheetah-2.2.2-1.fc11.x86_64 > > then python-web dumps to the browser as below, full traceback attached. > Downgrading back to > python-cheetah-2.0.1-5.fc11.x86_64 > > then all is good. > > File "/usr/lib64/python2.6/site-packages/Cheetah/Compiler.py", line > 1588, in __init__ > source = unicode(source) > > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position > 374: ordinal not in range(128) > > full back trace attached. Sorry about that, my fault. I hadn't finished testing Koji with the new Cheetah before I pushed it. This patch should fix the errors: http://mikeb.fedorapeople.org/0001-handle-all-strings-as-unicode-for-compatibility-with.patch It'll be pushed to the Koji git repo shortly.