buildsys September 2010

buildsys@lists.fedoraproject.org

18 participants
16 discussions

[BUG] Koji and Lustre
by Thomas Guthmann 09 Sep '11

09 Sep '11

Hey guys, We found a bug(?) in listTaskOutput (/usr/share/koji-hub/kojihub.py) when used with a Lustre filesystem. This function parses all attributes of every file of a build and is used when you want to display build.log/root.log through the web interface. Everything returned by listTaskOutput is returned through XML-RPC and as a result we had this : An error has occurred while processing your request. Fault: <Fault 1: 'exceptions.OverflowError: long int exceeds XML-RPC limits'> Traceback (most recent call last): File "/usr/share/koji-web/lib/kojiweb/publisher.py", line 16, in publish_object return old_publish_object(req, object) File "/usr/lib64/python2.4/site-packages/mod_python/publisher.py", line 412, in publish_object return publish_object(req,util.apply_fs_data(object, req.form, req=req)) File "/usr/lib64/python2.4/site-packages/mod_python/util.py", line 439, in apply_fs_data return object(**args) File "/usr/share/koji-web/scripts/index.py", line 649, in getfile output = server.listTaskOutput(taskID, stat=True) File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1468, in __call__ return self.__func(self.__name,args,opts) File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1718, in _callMethod raise err Fault: <Fault 1: 'exceptions.OverflowError: long int exceeds XML-RPC limits'> The issue comes from the st_dev value gathered by getStat (stat). In Lustre this value can be very high and that's why it complains. To fix that, we used the same condition than st_size, we cast the value as a string. See attached patch. Example (see 'Device:' the value after the '/'): # stat build.log File: `build.log' Size: 106021 Blocks: 208 IO Block: 2097152 regular file Device: e04ae70eh/3763005198d Inode: 721664 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 48/ apache) Gid: ( 48/ apache) Access: 2010-07-13 10:44:40.000000000 +1000 Modify: 2010-07-12 12:54:15.000000000 +1000 Change: 2010-07-12 12:54:52.000000000 +1000 # That's what is read by listTaskOutput relfilename=build.log ATTR=st_atime GETATTR=1278981616 relfilename=build.log ATTR=st_blksize GETATTR=2097152 relfilename=build.log ATTR=st_blocks GETATTR=208 relfilename=build.log ATTR=st_ctime GETATTR=1278903292 relfilename=build.log ATTR=st_dev GETATTR=3763005198 <----- /!\ relfilename=build.log ATTR=st_gid GETATTR=48 relfilename=build.log ATTR=st_ino GETATTR=721664 relfilename=build.log ATTR=st_mode GETATTR=33188 relfilename=build.log ATTR=st_mtime GETATTR=1278903255 relfilename=build.log ATTR=st_nlink GETATTR=1 relfilename=build.log ATTR=st_rdev GETATTR=0 relfilename=build.log ATTR=st_size GETATTR=106021 relfilename=build.log ATTR=st_uid GETATTR=48 Hope it helps, lost a good amount of time on that one :) Cheers, Thomas

2 3

Strange mock build failure due to typo
by Paul Howarth 24 Jan '11

24 Jan '11

Hi, today I have been preparing an update to perl-Math-Pari and came across a very strange build failure whilst doing a local mock build on a Fedora 13 x86_64 host. My package built successfully on x86_64 but when I tried to build for i386, the build failed during %setup but without any diagnostics. The SRPM was installed but no attempt to install its build requirements was made. The root.log showed an exit status of 0 for all commands that had been run. After much experimentation bisecting the changes I had made, I discovered that a typo in the changelog entry was the culprit: I had set the year to 2100 instead of 2010. So it would appear that somewhere in the mock/yum/rpm stack there may be a year 2038 problem waiting to bite us (though I suspect there may not be too many 32-bit builds happening by then). Seriously though, it would be nice to have better diagnostics for this and perhaps an rpmlint check for changelog entries in the future? Paul.

2 1

cannot open Providename index using db3 - Invalid argument (22)
by Vijay N. Majagaonkar 18 Oct '10

18 Oct '10

Hi, I am running out of strange problem at the time of creating ISO, ISO created successfully but it failed at the time of OS installation and this what i found in root.log file I am not able to under stand the what is the problem "cannot open Providename index using db3 - Invalid argument (22)" can someone please give me some point or direction to fix this, [Log] DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: Building isolinux directory DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: mkdosfs 2.11 (12 Mar 2005) DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: rpmdb: /var/lib/rpm/Providename: unsupported hash version: 9 DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: error: cannot open Providename index using db3 - Invalid argument (22) DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: rpmdb: /var/lib/rpm/Providename: unsupported hash version: 9 DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: error: cannot open Providename index using db3 - Invalid argument (22) DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: http://koji.fedora.com/packages/kernel/2.6.18/164.el5/x86_64/kernel-xen-2.6…: [Errno 12] Timeout: <urlopen error timed out> DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: Trying other mirror. DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: Traceback (most recent call last): DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: File "/usr/bin/yumdownloader", line 293, in ? DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: util = YumDownloader() DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: File "/usr/bin/yumdownloader", line 42, in __init__ DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: self.main() DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: File "/usr/bin/yumdownloader", line 80, in main DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: self.downloadPackages(opts) DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: File "/usr/bin/yumdownloader", line 214, in downloadPackages DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: path = repo.getPackage(download) DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: File "/usr/lib/python2.4/site-packages/yum/yumRepo.py", line 849, in getPackage DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: cache=cache DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: File "/usr/lib/python2.4/site-packages/yum/yumRepo.py", line 811, in _getFile DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: raise Errors.RepoError, errstr DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: yum.Errors.RepoError: failed to retrieve kernel/2.6.18/164.el5/x86_64/kernel-xen-2.6.18-164.el5.x86_64.rpm from anaconda-extrarepo-1 DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: error was [Errno 12] Timeout: <urlopen error timed out> DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: kernel (kernel-xen) doesn't exist for x86_64. skipping DEBUG util.py:256: /usr/lib/anaconda-runtime/buildinstall: Building minstg.img [/Log] Thanks for the help V!jay

2 3

email notifications
by Florian La Roche 05 Oct '10

05 Oct '10

Hallo, With koji-1.4 running on RHEL6-beta2, some email notifications are not sent out correctly: Traceback (most recent call last): File "/usr/sbin/kojid", line 1437, in runTask response = (handler.run(),) File "/usr/sbin/kojid", line 1513, in run return self.handler(*self.params,**self.opts) File "/usr/sbin/kojid", line 3649, in handler message = message.encode('utf-8') UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 546: ordinal not in range(128) Thie seems to happen e.g. on dejavu-fonts, ctags, crontabs, cronie, amanda, akonadi. regards, Florian La Roche

4 11

--tag option to spin-livecd or spin-appliance
by Jay Greguske 28 Sep '10

28 Sep '10

Hello, This patch implements a --tag option to the cli for the spin-appliance or spin-livecd directives. It causes the <target> parameter to be interpreted as a tag rather than a target. The patch includes minor changes to the client, builder, and some simple logic in the webUI to keep the task options listing clear to the user. Thanks, - Jay

1 0

Koji cli-build directory
by Alan Franzoni 24 Sep '10

24 Sep '10

Hello, just a small question. After several months of koji usage, i realize there's a dir, /mnt/koji/cli-build, containing temporary directories with .src.rpm, that's growing bigger and bigger. I suppose Koji is storing here the files he's being requested to build, but the dir never gets cleaned up. Is it safe to delete it? -- Alan Franzoni -- contact me at public(a)[mysurname].eu

4 4

Re: [MASH/KOJI] what about imported RPMs without a build ?
by Nathan Blackham 23 Sep '10

23 Sep '10

Did you tag the build? ------Original Message------ From: Thomas Guthmann Sender: buildsys-bounces(a)lists.fedoraproject.org To: buildsys(a)lists.fedoraproject.org ReplyTo: Discussion of Fedora build system Subject: [MASH/KOJI] what about imported RPMs without a build ? Sent: Sep 21, 2010 5:55 PM Hey guys, I've just discovered that mash does not include packages without a koji build despite the fact that a RPM has been imported (koji import --create-build [package]). Indeed, we have some packages already build with hudson/maven and not koji so we integrate them in koji to centralize RPMs. But then they don't appear in the generated mash repositories (used for cobbler). In mash/__init__.py:286, listTaggedRPMS does not include them. Is there a workaround (like another koji python method to use or some SQL black magic) ? Cheers, Thomas -- buildsys mailing list buildsys(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/buildsys Sent from my Storm2

4 7

[MASH/KOJI] what about imported RPMs without a build ?
by Thomas Guthmann 22 Sep '10

22 Sep '10

Hey guys, I've just discovered that mash does not include packages without a koji build despite the fact that a RPM has been imported (koji import --create-build [package]). Indeed, we have some packages already build with hudson/maven and not koji so we integrate them in koji to centralize RPMs. But then they don't appear in the generated mash repositories (used for cobbler). In mash/__init__.py:286, listTaggedRPMS does not include them. Is there a workaround (like another koji python method to use or some SQL black magic) ? Cheers, Thomas

1 0

Re:buildsys Digest, Vol 67, Issue 6
by lixiao＠nudt.edu.cn 21 Sep '10

21 Sep '10

In your responses,you said 'The task gets released by kojid when it restarts. its then picked up again and started over.' Howerver,if the task gets released,other builders should pick up the task.But they do not.The task does not go on until the builder powers on.Why?

3 2

the cache of the koji
by lixiao＠nudt.edu.cn 18 Sep '10

18 Sep '10

When I buid the packages in my koji1.3.2,one of the builders powered off.I found the task in the builder did not stop.The task can go on when I power on the builder.Why?Do the koji use the cache?I find in my os there is /var/cache/mock.Could anyone tell me how koji handle it?Thanks.

2 1

Mock umount all patch
by Alan Franzoni 17 Sep '10

17 Sep '10

Hello, I'm sorry needing to push this but I think it's really useful and I don't want it getting lost for no apparent reason. There was this feature for which I created a ticket: https://fedorahosted.org/mock/ticket/4 It was then discussed on the ml: http://www.mail-archive.com/buildsys@lists.fedoraproject.org/msg00178.html And it seemed all-right back then. http://www.mail-archive.com/buildsys@lists.fedoraproject.org/msg00244.html But still it was not applied. I pushed it forward once more recently, in order to cope with some recent modifications to the trunk: http://www.mail-archive.com/buildsys@lists.fedoraproject.org/msg00420.html Could it be applied now? Otherwise, if there's any pending issue, please tell me and I'll fix it. Thank you, -- Alan Franzoni -- contact me at public(a)[mysurname].eu

3 7

Problem configuring kojihub
by James Cammarata 17 Sep '10

17 Sep '10

I've followed the instructions (as best I can tell) to install kojihub/web on a RHEL5 system using the EPEL packages using the documentation here: http://fedoraproject.org/wiki/Koji/ServerHowTo I can access things in read-only mode, however when I try and login to kojihub from web interface or execute CLI admin commands, I get the following message: Traceback (most recent call last): File "/usr/share/koji-web/lib/kojiweb/publisher.py", line 16, in publish_object return old_publish_object(req, object) File "/usr/lib64/python2.4/site-packages/mod_python/publisher.py", line 412, in publish_object return publish_object(req,util.apply_fs_data(object, req.form, req=req)) File "/usr/lib64/python2.4/site-packages/mod_python/util.py", line 439, in apply_fs_data return object(**args) File "/usr/share/koji-web/scripts/index.py", line 183, in login if not _sslLogin(req, session, username): File "/usr/share/koji-web/scripts/index.py", line 70, in _sslLogin proxyuser=username) File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1458, in ssl_login sinfo = self.callMethod('sslLogin', proxyuser) File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1503, in callMethod return self._callMethod(name, args, opts) File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1548, in _callMethod raise err AuthError: could not verify client: None I assume this is because I've generated one of my SSL certs incorrectly (I've tried self-signed, as well as with our in-house CA cert), but I can't figure it out. I've regenerated all of the certs multiple times, but I can't get this working. Any tips on what I may have done wrong? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

2 2

Lazy man's koji setup
by Bryce 07 Sep '10

07 Sep '10

I was asked by a few folk off-list about the script I use to setup koji from scratch (Re: Subtle change in default behaviour or did I miss something in the docs?) I've tidied it up so that it uses a defaults file (which is the only thing you should have to edit) and stuck in a README to explain a few items. You can find the abomination here: http://zeniv.linux.org.uk/~bryce/koji/setup-koji-1.0.tar.bz2 I recommend you run it inside a shiney newly installed vm though. Also someone better qualified than myself should check that the postgres and firewall rules I used are sensible (well they work but that's not to say that they're right) Phil =--=

1 0

Re: newRepo task FAILED
by Pierre Guillet 07 Sep '10

07 Sep '10

I got the solution. I'm working on CentOS 5.5 and createrepo-0.4.11-3.el5 default package doesn't offer the python API ( /usr/lib/python2.4/site-packages/createrepo). It works with python-hashlib and python-createrepo installed (packages required for koji-builder in 1.4 and not in 1.3.2). 2010/9/3 Pierre Guillet <guillet.pierre(a)googlemail.com>: > Hello all, > > I'm installing Koji 1.3.2 on a CentOS5 system (all services on the > same server) and I have problem with newRepo task. > > I have used http://fedoraproject.org/wiki/Koji/ServerHowTo guideline > to configure koji and apache daemons and > http://fedoraproject.org/wiki/Koji/ServerBootstrap guideline to start > using koji. > Peux tu m'apporter ta lumière si tu connais bien koji ? > > I have imported SRPM in koji > > $ koji import hawai-webmin-1.510-1.hawai5.src.rpm > > I have created distrib and build tag, associated the RPM to the tag > and launched build for the tag > > $ koji add-pkg --owner hawai dist-hawai-5 hawai-webmin > $ koji add-tag --parent dist-hawai-5 --arches x86_64 "noarch" dist-hawai-5-build > $ koji add-target dist-hawai-5 dist-hawai-5-build > $ koji add-group dist-hawai-5-build build > > $ koji list-groups dist-hawai-5-build > build [dist-hawai-5-build] > kawai-webmin: None, default [dist-hawai-5-build] > > As a consequence koji has created newRepo task: > > $ koji list-tasks > ID Pri Owner State Arch Name > 237 15 kojira FAILED noarch newRepo [hwi06os.hawai.recouv] > 238 14 kojira FAILED noarch +createrepo [hwi06os.hawai.recouv] > 239 15 kojira FAILED noarch newRepo [hwi06os.hawai.recouv] > 240 14 kojira FAILED noarch +createrepo [hwi06os.hawai.recouv] > .... > > In kojid log repodata directory don't exist: > > 2010-09-02 14:25:01,979 [INFO] koji.build: Starting up > 2010-09-02 14:26:49,152 [INFO] koji.build.TaskManager: Attempting to > take task 161 > 2010-09-02 14:26:50,881 [INFO] koji.build.TaskManager: pids: {161: 22620} > 2010-09-02 14:26:51,358 [INFO] koji.build.TaskManager: open task: > {'waiting': None, 'id': 161, 'weight': 0.10000000000000001} > 2010-09-02 14:27:08,286 [INFO] koji.build.TaskManager: pids: {161: 22620} > 2010-09-02 14:27:08,757 [INFO] koji.build.TaskManager: open task: > {'waiting': True, 'id': 161, 'weight': 0.10000000000000001} > 2010-09-02 14:27:10,206 [INFO] koji.build.TaskManager: Attempting to > take task 162 > 2010-09-02 14:27:11,947 [INFO] koji.build.TaskManager: pids: {161: > 22620, 162: 22621} > 2010-09-02 14:27:12,432 [INFO] koji.build.TaskManager: open task: > {'waiting': True, 'id': 161, 'weight': 0.10000000000000001} > 2010-09-02 14:27:12,433 [INFO] koji.build.TaskManager: open task: > {'waiting': None, 'id': 162, 'weight': 1.5} > 2010-09-02 14:27:12,667 [WARNING] koji.build.TaskManager: TRACEBACK: > Traceback (most recent call last): > File "/usr/sbin/kojid", line 1285, in runTask > response = (handler.run(),) > File "/usr/sbin/kojid", line 1361, in run > return self.handler(*self.params,**self.opts) > File "/usr/sbin/kojid", line 2884, in handler > for f in os.listdir(self.datadir): > OSError: [Errno 2] No such file or directory: > '/tmp/koji/tasks/162/162/repo/repodata' > 2010-09-02 14:27:29,382 [INFO] koji.build.TaskManager: pids: {161: > 22620, 162: 22621} > 2010-09-02 14:27:29,855 [INFO] koji.build.TaskManager: open task: > {'waiting': True, 'id': 161, 'weight': 0.10000000000000001, 'alert': > True} > 2010-09-02 14:27:29,855 [INFO] koji.build.TaskManager: Waking up task: > {'waiting': True, 'id': 161, 'weight': 0.10000000000000001, 'alert': > True} > 2010-09-02 14:27:29,856 [INFO] koji.build.TaskManager: Task 162 (pid > 22621) exited with status 0 > 2010-09-02 14:27:29,890 [INFO] koji.build.TaskManager: Expiring > subsession 230 (task 162) > 2010-09-02 14:27:30,826 [WARNING] koji.build.TaskManager: FAULT: > Traceback (most recent call last): > File "/usr/sbin/kojid", line 1285, in runTask > response = (handler.run(),) > File "/usr/sbin/kojid", line 1361, in run > return self.handler(*self.params,**self.opts) > File "/usr/sbin/kojid", line 2841, in handler > results = self.wait(subtasks.values(), all=True, failany=True) > File "/usr/sbin/kojid", line 1448, in wait > return dict(session.host.taskWaitResults(self.id,subtasks)) > File "__init__.py", line 1302, in __call__ > File "__init__.py", line 1548, in _callMethod > Fault: <Fault 1: 'Traceback (most recent call last): > File "/usr/sbin/kojid", line 1285, in runTask > response = (handler.run(),) > File "/usr/sbin/kojid", line 1361, in run > return self.handler(*self.params,**self.opts) > File "/usr/sbin/kojid", line 2884, in handler > for f in os.listdir(self.datadir): > OSError: [Errno 2] No such file or directory: > \'/tmp/koji/tasks/162/162/repo/repodata\' > > In kojira logs repodata is not created : > > 2010-09-02 14:26:35,459 [INFO] koji.repo.manager: Created newRepo task > 161 for tag 4 (dist-hawai-5-build) > 2010-09-02 14:27:06,898 [INFO] koji.repo.manager: Found repo 82, state=INIT > 2010-09-02 14:27:31,906 [INFO] koji.repo.manager: Problem: newRepo > task 161 for tag 4 is FAILED > > I have RUNAS=root in /etc/sysconfig/kojira also no rights error (all > is launched on the same server) > > createrepo is available on the server and createrepo canal is added to > the server > $ koji add-host-to-channel hwi06os.hawai.recouv createrepo > GenericError: host hwi06os.hawai.recouv is already subscribed to the > createrepo channel > > kojira user has "repo" rights > > $koji list-permissions --user kojira > repo > > Any Idea ? > > Regards, > Pierre >

1 0

Fwd: Re: dist-git tag question
by Jesse Keating 03 Sep '10

03 Sep '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think this should go here for review. - -------- Original Message -------- Subject: Re: dist-git tag question Date: Fri, 06 Aug 2010 02:06:07 +0200 From: Karsten Hopp <karsten(a)redhat.com> To: Development discussions related to Fedora <devel(a)lists.fedoraproject.org> CC: Peter Hutterer <peter.hutterer(a)who-t.net>, Jesse Keating <jkeating(a)redhat.com> On 04.08.2010 07:05, Peter Hutterer wrote: > > I don't think git hashes are an equivalent to the nvr tags though. I may > have multiple commits for each nvr, a tag that explicitly specifies which > version ended up as an rpm in koji would be quite helpful. I have troubles > remembering hashes long-term, nvr is marginally easier. it also simplifies > things like "git diff foo-1.2-1..foo-1.2-2" or the automation of that > process. > > Cheers, > Peter I had similar problems identifying the correct git hash for my secondary arch rebuilds and complained about in in my blog on http://karstenhopp.livejournal.com/. The attached patch adds a --commitinfo parameter to koji's buildinfo and latest-pkg commands. P.e. koji buildinfo --commitinfo hwdata-0.227-1.fc14 returns git://pkgs.fedoraproject.org/hwdata?#21d5786ad6701422e71b3952ea3c8103c5ee72… The patch is for koji-1.4.0-2.fc13.noarch, but should be easy to adapt to latest Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyBYWYACgkQ4v2HLvE71NVl/QCdGjHMG5q6ILMPEQ0p/lQNJ4UC VVcAmwZr22Jeb+DeYtJHOvNGo0q32Kkl =RMPS -----END PGP SIGNATURE-----

1 0

newRepo task FAILED
by Pierre Guillet 03 Sep '10

03 Sep '10

Hello all, I'm installing Koji 1.3.2 (all services on the same server) and I have problem with newRepo task. I have used http://fedoraproject.org/wiki/Koji/ServerHowTo guideline to configure koji and apache daemons and http://fedoraproject.org/wiki/Koji/ServerBootstrap guideline to start using koji. Peux tu m'apporter ta lumière si tu connais bien koji ? I have imported SRPM in koji $ koji import hawai-webmin-1.510-1.hawai5.src.rpm I have created distrib and build tag, associated the RPM to the tag and launched build for the tag $ koji add-pkg --owner hawai dist-hawai-5 hawai-webmin $ koji add-tag --parent dist-hawai-5 --arches x86_64 "noarch" dist-hawai-5-build $ koji add-target dist-hawai-5 dist-hawai-5-build $ koji add-group dist-hawai-5-build build $ koji list-groups dist-hawai-5-build build [dist-hawai-5-build] kawai-webmin: None, default [dist-hawai-5-build] As a consequence koji has created newRepo task: $ koji list-tasks ID Pri Owner State Arch Name 237 15 kojira FAILED noarch newRepo [hwi06os.hawai.recouv] 238 14 kojira FAILED noarch +createrepo [hwi06os.hawai.recouv] 239 15 kojira FAILED noarch newRepo [hwi06os.hawai.recouv] 240 14 kojira FAILED noarch +createrepo [hwi06os.hawai.recouv] .... In kojid log repodata directory don't exist: 2010-09-02 14:25:01,979 [INFO] koji.build: Starting up 2010-09-02 14:26:49,152 [INFO] koji.build.TaskManager: Attempting to take task 161 2010-09-02 14:26:50,881 [INFO] koji.build.TaskManager: pids: {161: 22620} 2010-09-02 14:26:51,358 [INFO] koji.build.TaskManager: open task: {'waiting': None, 'id': 161, 'weight': 0.10000000000000001} 2010-09-02 14:27:08,286 [INFO] koji.build.TaskManager: pids: {161: 22620} 2010-09-02 14:27:08,757 [INFO] koji.build.TaskManager: open task: {'waiting': True, 'id': 161, 'weight': 0.10000000000000001} 2010-09-02 14:27:10,206 [INFO] koji.build.TaskManager: Attempting to take task 162 2010-09-02 14:27:11,947 [INFO] koji.build.TaskManager: pids: {161: 22620, 162: 22621} 2010-09-02 14:27:12,432 [INFO] koji.build.TaskManager: open task: {'waiting': True, 'id': 161, 'weight': 0.10000000000000001} 2010-09-02 14:27:12,433 [INFO] koji.build.TaskManager: open task: {'waiting': None, 'id': 162, 'weight': 1.5} 2010-09-02 14:27:12,667 [WARNING] koji.build.TaskManager: TRACEBACK: Traceback (most recent call last): File "/usr/sbin/kojid", line 1285, in runTask response = (handler.run(),) File "/usr/sbin/kojid", line 1361, in run return self.handler(*self.params,**self.opts) File "/usr/sbin/kojid", line 2884, in handler for f in os.listdir(self.datadir): OSError: [Errno 2] No such file or directory: '/tmp/koji/tasks/162/162/repo/repodata' 2010-09-02 14:27:29,382 [INFO] koji.build.TaskManager: pids: {161: 22620, 162: 22621} 2010-09-02 14:27:29,855 [INFO] koji.build.TaskManager: open task: {'waiting': True, 'id': 161, 'weight': 0.10000000000000001, 'alert': True} 2010-09-02 14:27:29,855 [INFO] koji.build.TaskManager: Waking up task: {'waiting': True, 'id': 161, 'weight': 0.10000000000000001, 'alert': True} 2010-09-02 14:27:29,856 [INFO] koji.build.TaskManager: Task 162 (pid 22621) exited with status 0 2010-09-02 14:27:29,890 [INFO] koji.build.TaskManager: Expiring subsession 230 (task 162) 2010-09-02 14:27:30,826 [WARNING] koji.build.TaskManager: FAULT: Traceback (most recent call last): File "/usr/sbin/kojid", line 1285, in runTask response = (handler.run(),) File "/usr/sbin/kojid", line 1361, in run return self.handler(*self.params,**self.opts) File "/usr/sbin/kojid", line 2841, in handler results = self.wait(subtasks.values(), all=True, failany=True) File "/usr/sbin/kojid", line 1448, in wait return dict(session.host.taskWaitResults(self.id,subtasks)) File "__init__.py", line 1302, in __call__ File "__init__.py", line 1548, in _callMethod Fault: <Fault 1: 'Traceback (most recent call last): File "/usr/sbin/kojid", line 1285, in runTask response = (handler.run(),) File "/usr/sbin/kojid", line 1361, in run return self.handler(*self.params,**self.opts) File "/usr/sbin/kojid", line 2884, in handler for f in os.listdir(self.datadir): OSError: [Errno 2] No such file or directory: \'/tmp/koji/tasks/162/162/repo/repodata\' In kojira logs repodata is not created : 2010-09-02 14:26:35,459 [INFO] koji.repo.manager: Created newRepo task 161 for tag 4 (dist-hawai-5-build) 2010-09-02 14:27:06,898 [INFO] koji.repo.manager: Found repo 82, state=INIT 2010-09-02 14:27:31,906 [INFO] koji.repo.manager: Problem: newRepo task 161 for tag 4 is FAILED I have RUNAS=root in /etc/sysconfig/kojira also no rights error (all is launched on the same server) createrepo is available on the server and createrepo canal is added to the server $ koji add-host-to-channel hwi06os.hawai.recouv createrepo GenericError: host hwi06os.hawai.recouv is already subscribed to the createrepo channel kojira user has "repo" rights $koji list-permissions --user kojira repo Any Idea ? Regards, Pierre

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

buildsys September 2010