Re: How to handel spinning when i686 versions of packages don't make it into the updates repo?
On 12/30/2009 02:05 AM, William F. Acker WB2FLW +1 303 722 7209 wrote: I've always noticed that when a package is updated, sometimes the i686 version isn't put into the x86_64 repo for updates. As a workaround, I Can you give some examples? If multilib content is inconsistent across updates then we really ought to sort that out. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: How to handel spinning when i686 versions of packages don't make it into the updates repo?
On 01/04/2010 11:32 AM, Jesse Keating wrote: Multilib set is dynamically determined each compose. If the package itself changes in a way that no longer triggers the multilib algorithm, then it will fall out of being multilib. Is there a mechanism to remove 'fallen' multilib packages? If not, couldn't there be update errors? For that matter, what if the lingering older multilib package contains a security flaw? My apologies if this has been discussed to death elsewhere. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: When and how the mock removes the build directories under the /var/lib/mock in koji building hosts
On 12/07/2009 08:57 PM, peng chen wrote: Hello, fedora-buildsys-list: Recently, one of my building hosts's mock directory usually be filled with build directories, I wonder why the build directories of finishing building task not to be removed immediately for make room for the coming task , yet they don't stay here untill some time elapses. So, When and how the mock removes the build directories under the /var/lib/mock in koji building hosts? Thanks! Jian's link is a bit confusing. There is a clearer explanation here: https://www.redhat.com/archives/fedora-buildsys-list/2009-June/msg3.html -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: how to cancel (stop) the build task which has strange state
On 11/24/2009 01:19 AM, peng chen wrote: hello, fedora-buildsys-list: I encounter with several strange build tasks, which build state is building,but task state is failed. resultly, these build tasks are always in the building state. I run command koji cancel ,but failed to cancel it ,it's still there(my koji website). So, how could I cancel (stop ) these strange build tasks. In addition, during these package building, the koji server and building host had poweroffed. Thanks! Answered here: https://www.redhat.com/archives/fedora-buildsys-list/2008-December/msg0.html -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: About priority on tag-inheritance
On 11/23/2009 12:58 AM, Dennis Gilmore wrote: On Sunday 22 November 2009 07:30:17 pm peng chen wrote: I wonder how the priority on tag-inheritance works. whether the priority number which is large has priority, or not? In other words, the larger the priority number is ,the priorer . is it like this? the smaller the number the higher priority 0 is higest followed by 1 etc yes, ala *nix process priority. Also like English usage (e.g. 1st priority, 2nd priority, ...) Note that the other priority values in Koji (task priority, external repo priority) work the same way. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Postgresql Database Error
On 11/18/2009 02:15 AM, peng chen wrote:
hello, fedora-buildsys-list:
when I requset a build task for pakcage anaconda to koji,
one errie error come out.
It detailed as follow:
pg.DatabaseError: error ' ERROR: new row for relation task violates
check constraint task_weight_check '
in ' UPDATE task SET weight=-0.9838856091396 WHERE id = 16296 '
I'm sure that the source rpm of anaconda is OK,because I succed to build
it in local mock environment. and
the repo is the same as the koji build server.
hope you do me a favor sincerely!
The system time on your hub must have been set back during an anaconda
build and there must be sufficiently few anaconda builds for this to
cause getAverageBuildDuration('anaconda') to return a negative number.
We should of course fix this, but you should also avoid rolling back the
time on your koji hosts, especially the hub and db hosts.
In the meantime, this patch should help
--- a/builder/kojid
+++ b/builder/kojid
@@ -2033,6 +2033,9 @@ class BuildArchTask(BaseTaskHandler):
avg = session.getAverageBuildDuration(name)
if not avg:
return
+if avg 0:
+self.logger.warn(Negative average build duration for %s:
%s, name, avg)
+return
# increase the task weight by 0.75 for every hour of build
duration
adj = (avg / 4800.0)
# cap the adjustment at +4.5
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
misguided flash player warning?
After updating Firefox it gave me the You should update Adobe Flash Player right now. page. However, I already have the latest version (10.0.32.18). I don't see anything newer. Am I missing something, or is Firefox just getting it wrong? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Suitability of Python for daemon processes
On Mon, Oct 26, 2009 at 12:41 AM, Dennis Gilmore den...@ausil.us wrote: On Sunday 25 October 2009 06:26:49 pm Jeroen van Meeuwen wrote: And koji.fedoraproject.org, no? koji is a mod_python app. it doesnt run as a daemon at all. but it it all python. There are python daemons in the system though. The builders run kojid, which is a daemon, and the process that triggers repo regeneration (kojira) is a daemon. Of course, these are not public facing -- they really only talk to the hub. The daemon distinction might be wrong thing to fixate on here. There is nothing in that distinction that should exclude python (or most any language). I think the real factors of concern are: size, complexity, speed, system load, robustness, and security. It's entirely possible to create large and complex systems with Python. It's expressiveness and interpreted nature are a big help here. Robustness is probably more a factor of design and good coding than the language itself. That being said, the relative ease of programming in Python, coupled with its exception handling, likely give it an advantage over C in this department (over the same development time at least). That's my opinion; others may disagree (and of course Python is not the only rapid development language with good exception handling). Security threats are everywhere. With Python at least you have to worry much less about buffer overflows, but of course you can introduce security flaws in any language. Obviously, as an interpreted language, system load and speed are where Python suffers. There are optimization tricks, but you'll never get close to execution speed of C. You can rewrite crucial portions in C, though I rarely see that actually done. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: the datails of Missing Dependency
On 10/19/2009 10:05 PM, xiao li wrote: This is the detailed information about Missing Dependency when I built the srpms.BuildrootError: could not init mock buildroot, mock exited with status 30; see root.log for more information.The attachment is the root.log.Please do me a favour.Thanks. You did not answer any of the questions I asked in my last email. If you want help, please re-read that email and answer them. https://www.redhat.com/archives/fedora-buildsys-list/2009-October/msg3.html -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Missing Dependency
On 10/15/2009 10:53 PM, xiao li wrote: Frist,thanks for your help. I have expired all the repos before I submitted the problem.As you said,I have executed the instruction to expire all the repos in the db.But the problem existed all the same.Do you have another solutions? Thanks for your reply. Please keep these discussions on the list. Your original email doesn't really indicate much other than missing dependencies. There are numerous possibilities. Can provide some details about the problem? What does your tag/target setup look like? Just to clarify -- Did you mean to say that your setup was working fine until you changed the ip address of a host? If so... - are you sure that was the only change? - was it only the ip address, or did the hostname change also? - which machine(s) changed address and what was running on them? - do your pkgurl and topurl settings in kojid.conf still reference an appropriate address? -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Missing Dependency
On 10/14/2009 03:57 AM, 李晓 wrote: Rencently,I changed the IP of my koji and regen-repo,but it shows missing dependency.The root.log as follows, By default, repo regens use the --update option against the last active repo. Because of this, old entries will persist. This is normally a helpful optimization, but when those old entries reference a now-changed url, it can be a problem. The fix is to expire the active repo. This will force a full rebuild of the repo (no --update). If you only have a few active repos, you can expire them on the command line like: % koji call repoExpire repo-id (the koji taginfo command will report the repo id of the active repo for the tag) If you have a lot of active repos (i.e. lots of different build targets), then the easiest way to expire them all is in the db. For example: = update repo set state = 2 where state in (0, 1); Once you've expired the repos, kojira should trigger the regenerations. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Adding builders without NFS access
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. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock rpmdb version issue with epel-5-i386 target
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 21
(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 :)
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock rpmdb version issue with epel-5-i386 target
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. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Can't Create repos
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). -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: about repo
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! -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: How can I waite for a new dist-foo-build repo
On 08/25/2009 10:02 PM, lixiao-a wrote: When I build a srpm,it can not waite genarate a new repo,it says. 1076 build (dist-foo, system-config-network-1.3.99-1.src.rpm): free 1076 build (dist-foo, system-config-network-1.3.99-1.src.rpm): free - open (kojibuilder) 1077 waitrepo (3): free 1077 waitrepo (3): free - open (kojibuilder) 1077 waitrepo (3): open (kojibuilder) - FAILED: GenericError: Unsuccessfully waited 120:58 for a new dist-foo-build repo As the error reports, the build already waited 2 hours for a repo and didn't find one, so it is not a matter of waiting. The system is not creating them. The most likely reasons for this are (as Jitesh wrote): 1) kojira not running 2) no hosts in the createrepo channel It is also possible that 3) createrepo jobs are failing If it is 1 or 2, that is an easy fix. Note that hosts in the createrepo channel need write access to /mnt/koji in order to succeed. If it is 3, you should look for failed createrepo tasks and see what the logs say. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: postgresql-server
On 08/18/2009 11:46 AM, Larry Brigman wrote: I have a server running several applications. They typically have the best support for mysql. Is there a hard reason for postgresql-server over mysql for koji? It hasn't been a priority to support multiple dbs. Postgres was chosen because we placed a high value on data integrity. The tables in Koji use a lot of 'serial' fields (integer fields linked to a sequence). In MySQL, the analog of this is an AUTO_INCREMENT field. It does not appear that this is a perfect analog. In any case, there would have to be a number of code changes due to this. If one were to use MySQL, they would most definitely want to use InnoDB tables, because Koji makes use of many foreign key constraints. Almost every table in Koji's schema has a CHECK clause somewhere in it. MySQL parses these, but /does not enforce them/. The types of data corruption that would result from entries that violate these checks would be quite insidious. I also expect there would be a number of subtle issues due to other behavior differences between the databases. With MySQL's reputation for quietly rolling along despite serious errors, you might not notice until the db was full of corruptions. So short answer: non-trivial amount of work to implement, even more for proper testing, questionable return for that effort. Running a Koji server is not intended to be lightweight. I don't think the postgres requirement is unreasonable. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Using koji to build Fedora ppc on i386
On Mon, Aug 17, 2009 at 2:42 AM, NGUYEN VAN TANtan2...@yahoo.com wrote: I'm wondering there is possible to build Fedora 9 PPC on an I386 Fedora 9 by using koji. If it is possible how to configure koji to do that. At present koji does not support cross compilation, though there was a thread with some patches last month. https://www.redhat.com/archives/fedora-buildsys-list/2009-July/msg0.html -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: fonts turning white?
On Mon, Aug 17, 2009 at 11:24 AM, Adam Williamsonawill...@redhat.com wrote: On Sun, 2009-08-16 at 18:19 -0500, Mike Chambers wrote: I have seen menus (firefox and evolution) and/or fonts turn white or missing on various occasions, no matter what I was doing. I've seen mention of gtk2 for various reasons, although this may or may not be a part of the problem. And what I mean by the problem, is the fonts are there and didn't leave, just not black no longer. They just seemed to fade out, or turn completely white and not be seen, or even be turned white but can see the letters. Anyone else experienced this and/or know what I am experiencing? If you're using nouveau, yes. If you install the latest xorg-x11-drv-nouveau and kernel from koji, it should cure that. I've been seeing random font corruptions, missing letters (I suppose they could just be white on white), sometimes the odd symbol-ish character instead of a letter. Intermittent. This is with the intel driver. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: When I modified the koji server'ip from one to another, the yum use the old ip already!
李建 wrote: Good,the method you give is simple.I'll test later.My repo table in sql now is following,Did you can tell me what's mean about state=3 ? and state=1 ,and state=2 ? from koji/__init__.py: REPO_STATES = Enum(( 'INIT', 'READY', 'EXPIRED', 'DELETED', 'PROBLEM', )) So 0 = INIT, 1 = READY, 2 = EXPIRED, 3 = DELETED Thank you very much ! I have draw a koji illustrative diagram , can you give me some advices? http://workplace.turbolinux.com.cn/attachments/120/koji%E5%8E%9F%E7%90%86%E5%9B%BE.png This link prompts me for a password -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: When I modified the koji server'ip from one to another, the yum use the old ip already!
李建 wrote:
I've solv this probole. the /usr/sbin/kojid have following code:
--
2584 #cmd.append('--update')
2585 #if options.createrepo_skip_stat:
2586 #cmd.append('--skip-stat')
==
I commented it , so the createrepo run as follow (see createrepo.log):
It seems a little silly to comment out code that can be disabled with a
configuration option (createrepo_skip_stat). Of course, there is no
option to disable the --update.
When I need to force the system to regenerate repos from scratch I just
expire them in the db. This works because kojid will only recycle
repodata from a repo in the READY state. Anyway, to expire all current
repos, I'd use this sql command:
- update repo set state = 2 where state in (0, 1);
You'll also need to cancel any newRepo tasks that were running beforehand.
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: How to remove the large directory after build ?
李建 wrote: Now ,the directory is: - [r...@localhost mock]# du -hs * 651Mgtes11.2-build-10-9 18M gtes11.2-build-13-10 5.6Mgtes11.2-build-15-15 549Mgtes11.2-build-1-6 5.5Mgtes11.2-build-16-15 18M gtes11.2-build-18-18 18M gtes11.2-build-19-18 Due to a potentially dangerous bug in rpmlib [1], kojid removes the mockdir directories in two stages. First the buildroot (e.g. gtes11.2-build-16-15/root)is cleared of content, but the directory itself (as well the mock results dir) remains. This clearing occurs almost immediately after most builds, but is delayed four hours for failed builds. After 24 hours, the entire mock directory for the chroot is removed. This allows any stray rpm transactions plenty of time to exit. This may seem like an extreme wait, but the consequences of triggering the rpm bug are very, very bad. [1] https://bugzilla.redhat.com/show_bug.cgi?id=192153 It appears that at least some of these directories (e.g. the 18M ones) are still in that 24 hour wait. As for the others, I cannot be sure from this small amount of data. ... Why ? Because I use a special disk space,and I use Selinux, So I modified the /var/lib/mock to /dist/mock on kojihub and kojiweb and kojibuilder3 host. but the kojibuilder2's mock directory is /var/lib/mock ,a link to /dist/mock on it's host. the kojihub and kojiweb and kojibuilder3's /mnt/koji directory is modified to /data/koji also . but the other kojibuilder*'s directory is /mnt/koji by nfs mount. Why ? It isn't change or removed after 1 days. As pointed out above, it is normal for koji's mock directories to survive (in a stripped form) for up to 24 hours. If the problem persists, I recommend cranking up the debugging on kojid and watching the logs (look for lines containing rootdir or buildroot). -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: No child processes
lixiao-a wrote: File /usr/sbin/kojid, line 2009, in handler broot.init()\n File /usr/sbin/kojid, line 467, in init rv = self.mock([\'--init\'])\n File /usr/sbin/kojid, line 389, in mock status = os.waitpid(pid, os.WNOHANG) OSError: [Errno 10] No child processes\n' It looks like the mock subprocess is dying before kojid can wait on it. Normally mock should never exit that fast, though we should probably handle that error a little more informatively. Try running mock manually on your build system to see if you can replicate the error that way. You might also try running kojid in the foreground (--fg option) in order to see the output from mock. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
mock and sha256 rpms
If you use mock for building, then you may be in the position of having the main system rpm use sha256 checksums (e.g. on F11) but create chroots that contain an older rpm that does not. If you create a source rpm using the newer rpm and pass it to mock to build in a chroot with an older rpm, you will get an error like the following: DEBUG util.py:256: error: unpacking of archive failed on file /builddir/build/SOURCES/INIT.2008-02-02.tgz;4a1e5c21: cpio: MD5 sum mismatch DEBUG util.py:319: Child returncode was: 1 I think the simplest way to work around this is to have mock pass --nomd5 to rpm when installing the srpm in the chroot. Of course, this is dropping an integrity check, so could possibly add a check outside the chroot to verify this data. Granted, I'm not sure what the best way to do that is. Thoughts? Concerns? -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: ActionNotAllowed: admin permission required
Lester Pimentel wrote: [kojiad...@testmachine ~]$ koji add-user kojira ActionNotAllowed: admin permission required I note the command prompt shows your (system) username as kojiadmin, the same as the koji username you have in the db below. Please note that there is no relationship between system users and koji users. Being logged into testmachine as kojiadmin does inherently mean the koji will treat you as the koji user of the same name. Check and see what user koji thinks you are (if any). Use this command: # koji call getLoggedInUser If it reports None, then you are not authenticating at all. Here's what my users look like in the koji db: id |name| password | status | usertype | krb_principal +- ---+--++--+--- 10 | koji | | 0 |0 | 12 | kojiadmin | | 0 |1 | Base on the name, I assume that kojiadmin is going to be your main admin account. However, it shows up with usertype=1 (build host). This is not a good idea. Builders as their own non-admin user, and admin accounts should not be flagged as build hosts. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: One build for multiple platforms?
Steve Traylen wrote: Is this check useful? It requires one to create to src.rpms before they can be submitted to dist-centos4 and 5. I can't for instance just grab a src.rpm package from fc10 and submit it. Koji likes to know the NVR it is building before it starts building it. This allows Koji to mark the build as in progress. It also allows Koji to detect nvr conflicts early (rather than at the end of the build). If the resulting build does not match this NVR then that is pretty big consistency problem I too have run into this quirk. It is not that difficult to remake the srpm with the right dist tag before submitting. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [PATCH] koji: Look at tail of build/root.log
Kedar Sovani wrote:
A lot of times the purpose of looking at the build logs is to look at the error
which usually appear at the end of the log. Provide a mechanism to look at the
tail
instead of downloading the entire log. (offset = -2000 is probably reasonable
enough as a default?)
This looks reasonable, though we should probably offer the option for
any *.log file from the task in question. We could just use:
#if $filename.endswith('.log')
Also, be careful of whitespace in patches. We don't use tabs in koji.
Also one line had trailing whitespace.
Please consider for inclusion.
Signed-Off-by: Kedar Sovani ked...@marvell.com
--- ./www/kojiweb/taskinfo.chtml.orig 2009-04-27 11:41:35.0 +0200
+++ ./www/kojiweb/taskinfo.chtml2009-05-03 10:06:55.0 +0200
@@ -287,7 +287,11 @@
thOutput/th
td
#for $filename in $output
-a
href=getfile?taskID=$task.idname=$urllib.quote($filename)$filename/abr/
+a href=getfile?taskID=$task.idname=$urllib.quote($filename)$filename/a
+ #if $filename == 'build.log' or $filename == 'root.log'
+ (a
href=getfile?taskID=$task.idname=$urllib.quote($filename)offset=-2000tail/a)
+ #end if
+ br/
#end for
#if $task.state not in ($koji.TASK_STATES.CLOSED,
$koji.TASK_STATES.CANCELED, $koji.TASK_STATES.FAILED) and \
$task.method in ('buildSRPMFromSCM', 'buildArch', 'createrepo')
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Is koji the right build tool for me? and some newbie questions
Zubin Sethna wrote: The problem here is python 2.5 since my build machine runs on RedHat Enterprise Linux 4 (ES) which uses an older version of python and I can't seem to find a python 2.5 RPM that will install on this OS. Also what is python(abi)? Do I have to install a full python 2.5 RPM to satisfy this dependency? You will need to rebuild koji under RHEL4 (or at least something more RHEL4-ish) if you want to run it on RHEL4. However 1) There are some build deps that are missing from RHEL4, you will need to provide them yourself (some may be in epel, others can be rebuilt for RHEL4). I know it is possible to build koji for RHEL4. But... 2) Once built, there are some additional runtime dependencies for koji, some of them indirect (koji-builder requires a recent mock, and mock requires lots of things). I think you can probably get koji-hub and kojira to run under RHEL4 without too much pain. Getting koji-builder on a RHEL4 box is going to be a world of pain (mainly because of mock and yum) -- save yourself the time and use RHEL5 for that. Deps you'll probably need: createrepo git mock python-cheetah python-elementtree python-krbV python-sqlite python-urlgrabber sqlite yum -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: problems of running koji on CentOS with EPEL packages
陈鲍孜 wrote: Thanks. However, how can I associate the kojid user with a build host? Does it mean that I have to configure a DNS to make all this names associate together? Or is there something that I need to configure which I may not have done? Build hosts need to be tracked in the koji database. You create these entries with the 'koji add-host' command. As I wrote before, this command will also create the associated user of the same name. Whatever name you used when you ran koji add-host, that is the user that kojid needs to authenticate as. At the beginning of wiki https://fedoraproject.org/wiki/Koji/ServerHowToProposed;, it is mentioned that - Builders By default these will be referred to as /kojibuilderX/, but can also be the hostname(s) of the boxes that will be setup as builders. TODO: can also or should ? I think this may be why I can't make it correctly. What I'm confused now is what the mentioned hostname(s). When you add build hosts in the koji db (with 'koji add-host'), you can give them any name you like. The document linked above presumes you will use names like kojibuilder1, kojibuild2, etc. However it notes that using the hostname (i.e. fqdn) of the machine that kojid will run on is also a reasonable choice. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: problems of running koji on CentOS with EPEL packages
陈鲍孜 wrote: Thanks, I think there may be something wrong configuring the host, because when I tried the command /usr/sbin/kojid -f to see what happened, it showed information such as below: Traceback (most recent call last): File /usr/sbin/kojid, line 2732, in ? main() File /usr/sbin/kojid, line 68, in main tm = TaskManager() File /usr/sbin/kojid, line 532, in __init__ self.host_id = session.host.getID() File /usr/lib/python2.4/site-packages/koji/__init__.py line 1133, in __call__ return self.__func(self.__name, args, opts) File /usr/lib/python2.4/site-packages/koji/__init__.py line 1380, in _callMethod raise err koji.AuthError: No host specified This is happening because kojid is authenticating as a user that is not associated with a build host (or perhaps not authenticating at all). You can't run kojid as a regular user (or anonymously). The hub is trying to determine which host is calling the function and is not finding one. Certain calls can only be executed by build hosts. When you created the host entry (koji add-host ...), an associated user was created with the same name. This is the user that kojid should authenticate as. And just to clarify, the users I'm talking about are the ones internal to koji, not the system users. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Koji: ServerOffline
Jitesh Shah wrote: I checked the logs. There is just a python traceback and the actual error ServerOffline: Database Outage' (This is with KojiDebug off) 'just' a python traceback? Often these are the key to the mystery. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [PATCH] don't break lines in logOutput (bz#467470)
Mike McLean wrote: Signed-off-by: Mike McLean [EMAIL PROTECTED] --- py/mock/util.py | 12 ++-- 1 files changed, 10 insertions(+), 2 deletions(-) Note, I removed the chomp() call since we're already splitting on '\n', hence none of the entries in the split can contain '\n'. We may want to remove the chomp function from util.py as this appears to have been its only use. Also, how would folks feel about removing the if line == '': continue bit? Empty lines in the output are still output after all. My main concern here is that the build.log produced by mock should be as accurate as possible. Context: https://bugzilla.redhat.com/show_bug.cgi?id=467470 https://fedorahosted.org/koji/ticket/113 -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Trying to figure out some umask issues
Jason L Tibbitts III wrote: I do a large number of local mock builds as a part of the package reviews that I do, and one problem I consistently run into is executables and .so files coming out with mode 775, but a scratch build in Fedora's koji instance showing the expected 755 permissions. I thought it might be some local environment leaking into my mock builds, but my personal umask is 022 which should be OK and changing it doesn't alter the result anyway. Init'ing a fresh chroot shows the default umask in it is 0002, which would seem to explain things but wouldn't explain why the Fedora buildsys has different results. Is there customization done there to force the umask somehow? I believe the umask needs to be 002 in order for users in the mock group to be able to use mock effectively. Regardless, if this is affecting your rpms, then your specs are probably broken. Use %defattr in all %files sections. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: caching packages on koji builder
Dan Horák wrote: Mike McLean píše v St 05. 11. 2008 v 15:14 -0500: So.. - repodata location determined by topurl/topdir options - rpm location determined by pkgurl option on the builder that created the repo. I admit, this is a bit of a mess. And I am lost there :-) Squid runs, url_rewriter works and I am still unable to cache the packages. What value is placed into the mock generated yum config? Look at the repo in question, use zless to view primary.xml.gz. Search for 'base=' -- the value of this field is determined by the pkgurl setting of the builder that created the repo. Regardless of how yum gets the repo, once it sees this in the metadata, it will use this base url to download the rpms. You need to make sure that this hits your squid server instead of the remote http server. There are a couple ways you might do this. 1 - change the pkgurl setting on all your builders and regenerate all your repos. 2 - leave pkgurl as-is, but use an iptables redirect on your builders to map it to the local squid proxy. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: caching packages on koji builder
Mike McLean wrote: This behavior is controlled by kojid options. If you specify the 'topurl' option for kojid, then the mock configs it generates will use an http:// url to point to the repo. Otherwise it will use a file:// url (using the value of the 'topdir' option, which defaults to /mnt/koji). Also, the use of a file:// url doesn't have to mean nfs. You could theoretically use another shared file system. So this is true, but misleading. The interaction of the topurl and pkgurl options in kojid is complicated. The topurl/topdir options determine how kojid will locate the repo. However, with the current code, the repodata will contain url references for the component rpms. That url is determined when the repo is generated. This happens during a createrepo task on a builder, and the pkgurl (not topurl) option is used. So.. - repodata location determined by topurl/topdir options - rpm location determined by pkgurl option on the builder that created the repo. I admit, this is a bit of a mess. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Koji probes
Doug Ledford wrote: A total of 3 sites probed the server 66.249.71.77 66.249.71.78 66.249.71.79 These reverse map to googlebot.com. A total of 6 possible successful probes were detected (the following URLs contain strings that match one or more of a listing of strings that indicate a possible exploit): /koji/fileinfo?rpmID=866filename=/usr/kerberos/bin/kpasswd HTTP Response 200 /koji/fileinfo?rpmID=1356filename=/usr/bin/ldappasswd HTTP Response 200 /koji/fileinfo?rpmID=1954filename=/usr/bin/vncpasswd HTTP Response 200 /koji/fileinfo?rpmID=3570filename=/usr/bin/vncpasswd HTTP Response 200 /koji/fileinfo?rpmID=3107filename=/usr/bin/ldappasswd HTTP Response 200 /koji/fileinfo?rpmID=2686filename=/usr/kerberos/bin/kpasswd HTTP Response 200 These links are all reachable via the web ui, any crawler might will hit them. I suggest adding a robots.txt to keep crawlers out. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [Server-devel] Tying yum to a package stream?
Martin Langhoff wrote: As it's a single package and this could expand to a couple more packages but no more, one alternative is to take that single package and rename it ejabberd-xs and set it to provide:ejabberd, conflicts:ejabberd. If you go this route, I think what you want is obsoletes. Obsoletes says this packages replaces this one. Conflicts says this package cannot be installed at the same time as this other one. One mechanism gives the tools instruction on how to handle things, the other is more of an assertion that mostly just causes the end user pain when it comes up. Building conflicts into your repositories is generally not very friendly. Sometimes it may make sense, but I'm not sure it makes sense here. I am already down that path with Moodle (moodle-xs), which I plan to maintain as a long-term heavily customised package. Instead clone the Fedora repo. removing the packages you want to override Quite a bit of work if I also want to give them access to sec updates in a timely fashion :-) and my conflict with Fedora packages is tiny. I think you could come up with a reasonably fast sync script if you wanted to go this way. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Supporting EPEL Builds in Koji
Mike Bonnet wrote: On Fri, 2008-07-18 at 11:38 -0400, Mike McLean wrote: Mike Bonnet wrote: On Thu, 2008-07-17 at 13:54 -0400, Mike McLean wrote: If the remote_repo_url data is going to be inherited (and I tend to think it should be), then I think it should be in a separate table. ... I don't have any problem with this, though it does mean we'll need to duplicate quite a bit of the inheritance-walking code, ... Walking inheritance is just a matter of determining the inheritance order and scanning data on the parent tags in sequence. ... Sorry, I was referring to walking tag_inheritance. I'd rather have one place that walks the inheritance hierarchy and aggregates data from it, than two places that are doing almost the same thing. We're talking about inherently different data. External repos to be merged in are quite different from builds in the system. Each tag has a set of builds associated with it. We walk the inheritance hierarchy, aggregating the builds from each tag in the hierarchy into a flat list, and then pass that list to createrepo. We would do essentially the same thing for external repos. When walking the hierarchy, if a tag has an external repo associated with it, we would append that repo url to a flat list, and pass that list to mergerepo. In both cases we're working with collections of packages that are associated with a tag, just in different formats. Sure, we can do this with one call to readFullInheritance, and traverse both the build table and external repo table from the given order. In discussing this with Jesse, I think we want external repos to be inherited. This is probably the easiest way to deal with having multiple external repos getting pulled in to a single buildroot, which is essential for Fedora (think F9 GA and F9 Updates). The idea was that, by convention, we would have external-repo-only tags, with only a single external repo associated with it and no packages/builds associated. These external-repo-only tags could then be inserted into the build hierarchy where appropriate. An ordered list of external repos could then be constructed by performing the current depth-first search of the inheritance hierarchy. The ordered list would then be passed to mergerepo, which would ensure that packages in repos earlier in the list supersede packages (by srpm name) in repos later in the list. This would preserve the first-match-wins inheritance policy that Koji currently implements, and that admins expect. For example: dist-custom-build ├─dist-custom └─dist-f9-updates-external └─dist-f9-ga-external would result mergerepo creating a single repo that would only contain packages from dist-f9-ga-external if they did not exist in the Koji-generated repo (dist-custom-build + dist-custom), dist-f9-updates-external, or the blacklist of blocked packages. This is consistent with how Koji package inheritance currently works, and I think is the most intuitive approach. It is similar, but different in potentially confusing ways. External repos do not have build structure, so we can't really have the same sort of inheritance behavior with a combination of external repo tags and normal tags. We order the external repos in inheritance order, but ultimately those repos are merged with the internal one in a way that does not honor inheritance in the way that the admin might expect. Using tags to represent external repos fails intuition because external repos are very much not like tags. When we get to supporting external koji systems, we can do something like this, but for external repos the bolted-on nature needs to be clear. This is why I'd prefer to have the data a little more removed. I see all that, and I'm almost convinced. The flipside is that by default all the code will treat these external rpms the same as the local ones, which will not be correct for a number of cases. Personally I'd prefer adding a few special cases to the existing code, rather than maintain a whole heap of almost-but-not-quite-the-same code to manage external rpms. I think that conceptually they're alike enough that the number of special cases will be minimal. I think I'm ok with using the rpminfo table. I think that synthesizing builds for that sake of maintaining the not-null constraint is more pain than it's worth, and would make enforcing our nvr-uniqueness constraints (which we definitely want to do for local builds) more difficult. Having locally-built rpms always associated with a build, and external rpms not, makes sense to me. Ok, agreed. Also, I'm thinking we need to have some sort of rpm_origin table so that all these references can be managed cleanly. That sounds reasonable to me. Note that we may end up with a lot of rows in this table, since we're allowing variable substitution in the external_repo_url (tag name and arch). But I don't see that as a problem. I'm thinking the only substitution we should support is arch
Re: Broken dependencies: perl-Test-AutoBuild
Jesse Keating wrote: On Thu, 2008-09-18 at 00:49 -0400, Jens Petersen wrote: How does that stop perl-Test-AutoBuild-darcs.noarch getting into ppc64 trees? ExcludeArch ExcludeArch is odd, and is distinctly tied to the build. Note that only srpms get the ExcludeArch/BuildArchs/ExclusiveArch data in their headers; the built rpms do not have this data. While certain tools might theoretically be able to look up the matching srpm, check this data, and enforce it in some way for the built rpms, I don't believe there is any way to signal such restrictions only for a sub-package. In any case, such use seems a little fragile and sketchy to me. I'm not that familiar with Pungi's capabilities. Can it be told to special-case situations like this with a config? If Pungi is performing the roundabout ExcludeArch lookup I described above, then you might need to split the arch-limited subpackage into its own srpm in order to take advantage of that. I'm not sure if that is any better for you than moving the package away from noarch. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: What exactly is 'latest'
Bryce wrote: when I look at latest-by-tag I get kernel-2.6.9-42.32.0.0.4.EL instead of kernel-2.6.18-8.1.6.0.18.el5 So I'm wondering if the koji code is simply making a character by character comparison Note that latest-by-tag is an odd and misleading report that was submitted by a developer. I would not it. Use latest-pkg or list-tagged --latest instead. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Kojihub xmlrpc log spewage
Doug Ledford wrote: Can anyone tell me how to make the postgresql code in the xmlrpc engine not spew all over my httpd error log? In less than 1 week I have in excess of 500MB of stuff like this: edit /etc/httpd/conf.d/kojihub.conf, ensure KojiDebug is not set -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Kojihub xmlrpc log spewage
Doug Ledford wrote: On Thu, 2008-08-07 at 12:06 -0400, Mike McLean wrote: Doug Ledford wrote: Can anyone tell me how to make the postgresql code in the xmlrpc engine not spew all over my httpd error log? In less than 1 week I have in excess of 500MB of stuff like this: edit /etc/httpd/conf.d/kojihub.conf, ensure KojiDebug is not set Yeah, did that already...no change. Is KojiDebug set to any value at all (e.g. 'no')? It appears that one part of the code may misinterpret a non-null value as enabled. A bug, to be sure, but in the meantime, best to make sure there is no uncommented 'KojiDebug' value of any sort. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Yum Static Repos
Brian Schubert wrote: Is kojira capable of creating static repos such as those at http://koji.fedoraproject.org/static-repos/ or is this achieved through some other means? Either way, would anyone be able to instruct me as to how it's done? Short answer: not really, but it is not hard to accomplish yourself Longer answer: kojira doesn't actually create repos at all. It tracks what repos are needed and whether they are current. When a repo is needed that does not exist, or when one is out of date, kojira creates a koji task asking the builders to create the repo. Actually, the repos that are created by the process /are/ static, they just have a complicated path (involving the repo id and tag name). A koji repo, once created, remains the same until it is deleted. If tag content changes, a new repo will be created. So, this term 'static-repo' is unfortunate. What folks really mean is 'slowly changing repo at a convenient location.' One way to get such a thing is to make a cronjob that periodically copies the current active repo for a tag to a fixed location. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: YUM security issues...
On Mon, Jul 28, 2008 at 5:29 PM, seth vidal [EMAIL PROTECTED] wrote: On Mon, 2008-07-28 at 17:28 -0400, Mike McLean wrote: Would it be feasible to audit the mirror content? We have the list of mirrors, we know what the content should be. I think we'd only need to validate the mirrored repomd.xml, right? Doesn't seem to onerous... yes, yes, not perfect, malicious mirror could change the content, etc, but at least we'd have some measure of detection. which is the point. A malicious mirror could safely lie to us and not lie to their targets. Depends on who 'us' is. We could run such checks from a number of different locations. Anyway, I didn't mean to suggest this as a total solution. Additionally, mirrormanager DOES check the mirrors. Good to know. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: YUM security issues...
On Mon, Jul 28, 2008 at 5:38 PM, seth vidal [EMAIL PROTECTED] wrote: On Mon, 2008-07-28 at 17:37 -0400, Jeremy Katz wrote: Except, of course, for mirrors which are internal to a specific site and thus can't be contacted by MM and if they're evil then the folks involved are screwed anyway Well, depends. Having an evil system on an internal network is bad, but not as bad as having your servers compromised. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: building from git using custom koji install
Jesus M. Rodriguez wrote: I've tried several versions of the url with no luck. It seems that koji expects the scm repository house a single package which is not the case for us. There are innumerable ways that one might build an srpm from an SCM checkout. Koji can only support a limited set. Basically, your SCM layout must support koji, not the other way around. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: GenericError Repo directory missing
Naveen Gavini wrote: Does the /mnt/koji/repos directory exist? Is it owned by the same user httpd runs as? Also, have you tried to change topdir to something other than /mnt/koji? There are known problem with this, it needs to be fixed. We were able to fix this. The problem seemed to be that we did not have this directory (/mnt/koji) mounted on the builder, it was only mounted on the hub which runs kojira. We thought since kojira was creating the repos directories that would suffice. It also needs to be accessible by the builder. It depends on how you configure the builder. If you specify a topurl value, them the builder will access the repos via http. Otherwise it will access them via the filesystem under /mnt/koji. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Supporting EPEL Builds in Koji
Mike Bonnet wrote: On Thu, 2008-07-17 at 13:54 -0400, Mike McLean wrote: If the remote_repo_url data is going to be inherited (and I tend to think it should be), then I think it should be in a separate table. I'd like to reserve tag_config for data that is local to individual tags. This will also make it easier to represent multiple remote repos. I don't have any problem with this, though it does mean we'll need to duplicate quite a bit of the inheritance-walking code, or make it configurable as to which inheritance it's walking. This new table would also have to be versioned, the same way the tag_config table is. Walking inheritance is just a matter of determining the inheritance order and scanning data on the parent tags in sequence. Currently, nothing scans tag_config in this way because no data in tag_config is inherited. (Well, in a sense tag_changed_since_event() does walk tag_config, but that's a little different.) We need to figure out how we'll deal with multiplicity for the external repos. If tag A uses repo X and inherits from tag B which uses repo Y, then does tag A use both X and Y, or does the X entry override it? A (+repo X) +- B (+repo Y) My inclination is that it should override, because I think we'll want some way to do override that that mechanism seems easiest. Also, I think we'll probably want to allow multiple external repos per tag, something which will be much easier to represent in an external table. We can include an explicit priority field to make a sane uniqueness condition (and to provide a clear ordering for the repo merge). The big win here is that the methods and tools that query rpminfo for information about what was present in the buildroot at build time -snip- I see all that, and I'm almost convinced. The flipside is that by default all the code will treat these external rpms the same as the local ones, which will not be correct for a number of cases. Obviously, part of this will involve changing code to behave differently for the external ones, I'm just worried about how much we might have to change, or what we might miss. Yes, I realize that the not null constraint should exist now, and in fact all rpms in the Fedora database do reference builds. However, I think logically having a remote rpm not reference a local build makes sense. The alternative is to create the build object from the srpm info in the repodata (along with some namespacing similar to rpminfo). However, this would significantly clutter the build table with information that is pretty non-essential. The idea of grouping them into builds appeals to me, but I don't think it's possible in general (though maybe we could fake it well enough somehow). The only data we're (mostly) guaranteed to have to work with is the sourcerpm header field. The catch is that in case of an nvr-collision we can't determine which build it belongs to (or indeed if we should create a new build of same nvr). I'm open to suggestions on how to modify the uniqueness constraint to handle this case. We care about ensuring that a locally-built rpm doesn't have the same n-v-r as another locally-built rpm. I don't think we care at all about n-v-r uniqueness amongst remote rpms. However, we probably want to avoid creating 2 rpminfo entries when the same remote rpm is used in 2 different buildroots. Using the sigmd5 is a good way to avoid that. Agreed. same sigmd5 == same rpm. However, what happens if a remote rpm with the same n-v-r and sigmd5 gets pulled in from 2 different remote repos? This gets into part of what bugs me about this and why I'm somewhat inclined to keep the ext repo data a step removed. It's so potentially dirty. Koji has all these consistency constraints that an external repo (much less many of them in aggregate) lacks. It's quite possible that an external repo might respin a package keeping the same nvr, so we don't even need 2 external repos to hit this possibility. Perhaps the origin field should be pushed down to the buildroot_listing table, so the buildroots can reference the same rpminfo object, but indicate that it came from a different repo in each buildroot? Interesting. Yeah, I think that is is probably the right answer. Also, I'm thinking we need to have some sort of rpm_origin table so that all these references can be managed cleanly. Also, what happens when we find 2 remote rpms with the same n-v-r but different sigmd5s? Should that be an error? Certainly we have to allow the possibility that two origins might have overlapping nvras. Within a single origin, I'm not so sure. I suppose we can get away with some small consistency demands. As long as we're only enforcing unique nvra for local builds and indexing by sigmd5/similar, I don't think we /have/ to make this an error condition. In the same vein, what happens when an external repo has an nvra+sigmd5 matching a /local/ rpm? Maybe it doesn't matter, though I guess
Re: koji.build: Session expired
Paul B Schroeder wrote: If this is already the case, you may just need to specify topdir in kojira's config or make a symlink. I'm running all of this on one system for now. So it's not an issue yet. So does /mnt/koji/repos not exist? I've made apache the owner of /mnt/koji and everything below it so I could import packages. But that doesn't feel right though. I suppose I could/should run the web server as kojibuilder? I usually just use the apache user. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: koji add-group?
Paul B Schroeder wrote:
Hmm.. Strange.. I don't seem to have the add-group command (see
further below). I had to do this via psql to be able to koji
add-group-pkg:
The add-group cli command was added in git almost a year ago. However,
the stock koji build in the F8 repos is really, really old.
As mikeb pointed out you can pull a later koji build from the koji.fp.o.
Optionally, you could just build it yourself from a git clone. If you
don't want /quite/ the bleeding edge, you could build from the
koji-1.2.5-1.fc8 tag.
koji= insert into groups (name) values('build');
INSERT 0
Even if your cli doesn't have the add-group command, the hub still has
the call. Rather than muck around in the db, you could have just run:
$ koji call groupListAdd tag group
[EMAIL PROTECTED] koji]# rpm -q koji
koji-1.2.2-2.fc8
yep. old, old, old.
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: koji.build: Session expired
Paul B Schroeder wrote: Traceback (most recent call last): File /usr/sbin/kojira, line 497, in module main() File /usr/sbin/kojira, line 323, in main repomgr.pruneLocalRepos() File /usr/sbin/kojira, line 203, in pruneLocalRepos for tag in os.listdir(topdir): OSError: [Errno 2] No such file or directory: '/mnt/koji/repos' kojira requires write access to your file store so that it can delete old, expired repos. You can either run it on the same machine as the hub or a different machine which has that filesystem somehow exported to it. If this is already the case, you may just need to specify topdir in kojira's config or make a symlink. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: koji clone-tag?
Jesse Keating wrote: I don't know if I've pushed any koji updates for F-8 since the server side of things changed a lot and may not work with current F-8 toolings. Given that the client is tied to the server it makes it rather hard to do client updates. I'm pretty sure the F8 updates are sufficient to run koji. I've had an F8 system running koji development code (hub, client, builder, and kojira) for a while now. $ koji latest-pkg --quiet dist-f8-updates mock yum createrepo python-krbV mock-0.9.7-2.fc8 dist-f8-updates jcwillia yum-3.2.8-2.fc8 dist-f8-updates skvidal createrepo-0.4.11-2.fc8 dist-f8-updates lmacken python-krbV-1.0.13-6.fc8 dist-f8 mikeb Well, ok, I'm cheating a little bit. I previously had to make skip-stat optional in kojid (change committed on the shadow branch), but that appears to no longer be necessary since createrepo-0.4.11-2.fc8 has the skip-stat patch. http://koji.fedoraproject.org/koji/buildinfo?buildID=32381 -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
cacti misreports koji disk space
For a while I would look at the /mnt/koji space graph in Cacti and say to myself boy, garbage collection sure has managed to slow the growth in space usage. The graph was really leveling off. https://admin.fedoraproject.org/cacti/graph.php?action=viewrra_id=alllocal_graph_id=280 But then I realized: it's too level. If you get the csv data from Cacti, the numbers for the last few months are identical. The data shows 2.1990232545e+12 used, which is suspiciously close to exactly 2T (and wrong, df reports 2.7T). The free space is stuck at the same number. Oddly the total space is reported as 4.3980465091e+12, which is almost exactly 4T (and also way wrong, df reports 9.9T). Anyway, given the numbers it looks like some sort of maxint issue. Does anyone know if there is a fix? ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Koji hidden packages proposal
Dennis Gilmore wrote: What im talking about was the proposal put forward when we had the buildsys meeting the proposal that we all said sounded like the way to move forward. This is not that proposal. importing packages is the one thing that hurts koji from getting wider use outside of fedora. Some people will import the data. Most do not want to. Fedora will be mirroring RHEL content from RHN, people outside of fedora will be mirroring fedora and building on top of that. All that was really concluded at the meeting was that Mike and/or I would create a proposal. As I said in that meeting there are basically two approaches: import and hide or find a sane way to use external repos. Mike's proposal is the former. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Moin 2.0 (or as I call it, mediawiki)
Mike McGrath wrote: So I spent some time last night and produced this: https://publictest1.fedoraproject.org/wiki/index.php/FedoraMain Are the mediawiki access controls sufficient for our needs? iirc they are pretty limited compared to moin's, but I'm not sure to what extent we're using them. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Killing build jobs - mock python processes survive
Michael Schwendt wrote: Does that work successfully in koji? Here, the mock Python processes survive the kill signal. Only the parent mock process terminates. The other ones keep building until the job succeeds or fails. Koji is pretty aggressive about killing off task processes. https://hosted.fedoraproject.org/koji/browser/builder/kojid#L863 -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: New upstream release of Koji (and a refresh of Fedora builders?)
Dennis Gilmore wrote: I have no issues with that at all. i would prefer we do it so we are not carrying patches. Id like to see the patches that i submitted included also. It will help in secondary arch ramp up over the next couple of weeks Keep in mind, we'll probably be working from the shadow branch for a little while. We may need to build our own releases for secondary arch until the kinks are worked out. (Of course changes that need to make it to koji.fp.o are a different story). -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
small fix for kojihub tonight
There is a bug in kojihub that is blocking deletion of some builds. The fix is very small and will only affect garbage collection. After talking with mmcgrath, I'm planning on applying this fix to koji.fp.o tonight and restarting the hub. I'll choose a time when the build queue is empty (or at least sparse). The patch is here: https://hosted.fedoraproject.org/koji/changeset/eb1c53de6e3bea423864dd260f1f5bd3ae77ba6d ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Koji
Oscar Victorio Calixto Bacho wrote: which are case use for koji? Koji is a system to manage rpm builds via mock on a farm of builders. It does a lot to manage this, but at the end of the day that is what it is for. case use from development, list actors, etc., administrator manual. I feel like we're losing something in translation. Are you looking for documentation? We're a little light on administrative docs right now, but I plan to have something better in the next month or so. In the meantime, there is this page: http://fedoraproject.org/wiki/Koji/ServerHowTo -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Integrating deltarpm creation
Jeremy Katz wrote: The first thing is that it makes the most sense for the deltas to be created and stored by koji rather than as a secondary process. This adds the advantage that they're stored consistently with the packages and also can be cached rather than recreated every time. It feels somewhat analagous to me to the current situation with signing. While I see the semi-parallel with signatures, I'd rather not rush into adding this to koji. I'd like to have a better understanding of how these deltas need to be managed. Do we anticipate Koji actually having a use for the deltas, or would it just be storing them for other tools? Can deltarpms be signed independently of the rpms it compares? If so, we may need to think about tracking these signatures. How should we deal with the delta/signature interaction? Is there a quick way to read the target's signature info from the delta (applydelta -i doesn't seem to report it)? Each rpm in koji can have multiple signatures, and we would presumably care which signature will be used for the target rpm in the delta. This leads me to wonder about naming schemes and api needs. With signatures, the cached files are tiny, there are unlikely to be more than a handful of them per rpm, and it is clearly reasonable to keep them for as long as the rpm is kept. Even deltas for trivial cases seem to be much larger than a cached signature header, and one can imagine accumulating a large number of deltas for an rpm. So the question is, how long should deltas be kept, and what should trigger their removal? -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Discussion summary: Mock security
Clark Williams wrote: Michael E Brown wrote: On Wed, 2006-06-07 at 19:52 -0400, Mike McLean wrote: At the moment, mock runs as a mortal user and uses mockhelper to execute a limited number of shell commands as root. What I'd like to do is have mock-helper (possibly renamed) run mock.py (and only mock.py) as root, letting mock.py take actions directly without having to filter back through mockhelper. Ok, so this is the coolest proposed solution I have seen to this problem. I like it a lot. How would we tell that the mock.py being run as root is the mock.py we all know and love (and not one defiled by some black hat)? So mockhelper would continue to perform env sanitation, and I imagine it will have a hard-coded path for mock.py. I suppose if we're really paranoid we could store the sha1sum of mock.py at compile time and check it at runtime, but I think restricting to running mock.py from the standard location is sufficient. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
