Re: How the pkglist of the repo associated with build tag is generated
On Thursday 19 November 2009 07:28:52 pm peng chen wrote: for example,I have a target dist-test, it's detailed info as follow: Name Buildroot Destination -- dist-testdist-test-builddist-test I use command koji list-tagged dist-test,and found the package in the list of dist-test,but when generating the repo associated with the build tag 'dist-test-build',the package doesn't exist in the file 'pkglist'.This results in Missing Dependency Error or Init mock buildroot Error. I reslove the problem this way that tag the missing package with command koji call tagBuildBypass dist-test-build the missing package n-v-r ,and then regen-repo,It's OK! So, I wonder why and how the content of file 'pkglist' is written? Thanks, sincerely! does dist-test-build inherit from dist-test ? im guessing not koji list-tag-inheritance dist-f12-build dist-f12-build (86) ├─dist-f12-override (113) │ └─dist-f12-updates (105) │ └─dist-f12 (85) │└─dist-f11-updates (87) │ └─dist-f11 (62) │ └─dist-f10-updates (64) │ └─dist-f10 (45) │└─f9-cutoff (110) └─dist-f11-build (63) ├─dist-f11-override (89) └─dist-f10-build (46) ├─dist-f10-override (68) └─f9-build-cutoff (111) in fedoras koji koji add-tag-inheritance dist-test-build dist-test should set you up you may need to use --priority and specify one if you have other tags already inherited. Dennis signature.asc Description: This is a digitally signed message part. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Signing RPMs
On Wednesday 11 November 2009 07:15:36 am Josh Boyer wrote: On Tue, Nov 10, 2009 at 11:24:50PM -0800, Jitesh Shah wrote: So, I picked up the sign_unsigned.py script from releng. I replaced the keys in there with our keys, tweaked some minor stuff here and there and managed to get it running. I use it as ./sign_unsigned.py --level level tag-name and it runs alright. I can see that the signatures are cached under the sigcache directory (but NOT embedded in the rpms themselves, which makes sense since the rpm can probably be a part of different tags and might be signed differently within each tag) So, I thought, well, mash would be the one which'll embed the keys in the rpms. So, I set strict_keys to True.. added my key to the keys list in my .mash file. mash has no problems with the rpms and it can verify the signatures alright. But, it still doesn't embed the signatures in the rpm (is it supposed to?). So, the created repository still has all rpms unsigned. What am I missing here? where to the rpms get signed actually? The sign_unsigned script should eventually do a koji API call to do 'write-signed-rpm' on the packages you are signing. That will assemble signed RPMs in koji itself, which mash will download and used. Fedora Rel-Eng doesn't use sign_unsigned anymore because we have a signing server setup now. However, it should still work. it still works. EPEL releng still uses it. you need to make sure to add -- write-rpms to you command. the signed rpms will then get written. Dennis signature.asc Description: This is a digitally signed message part. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: the datails of Missing Dependency
On Monday 19 October 2009 09:05:44 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 seem to be missing perl bash and a few other essential packages from the buildroot. make sure that they are available via koji latest-pkg tag name package name Dennis signature.asc Description: This is a digitally signed message part. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Mock issue with ifarch BuildRequires
Em Domingo 12 Julho 2009, às 06:38:31 pm, Gianluca Sforna escreveu:
I am trying to run the tests included in the BuildBot package during
the RPM build, and one of the tests requires darcs, which is built in
Fedora ExclusiveArch %{ix86} x86_64 ppc alpha.
Now, I'm adding to buildbot's spec[1] file an ifarch like:
%ifarch %{ix86} x86_64 ppc alpha
# darcs ExclusiveArchs
BuildRequires: darcs
%endif
but it seems darcs is never installed in the buildroot [2]
am I just doing something stupid or there's a bug somewhere?
[1]
http://cvs.fedoraproject.org/viewvc/rpms/buildbot/devel/buildbot.spec?view=
log [2]
http://koji.fedoraproject.org/koji/getfile?taskID=1470380name=root.log
What arech are you building the srpm on? if its not one of the ifarch'd
arches it wont be in the BR's for the srpm. thats part of why we create the
sroms on th ebuild arch in koji.
Dennis
signature.asc
Description: This is a digitally signed message part.
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock and sha256 rpms
On Thursday 28 May 2009 10:49:57 am Mike McLean wrote: 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 Makefile.common has # to make srpms on F-11 and newer for older releases use old hashes # F-10's rpm supports both styles F-9 is the only current release # outside of rhel that needs old hasnes ifeq ($(DISTVAR),rhel) RPM_DEFINES := $(RPM_DEFINES) \ --define _source_filedigest_algorithm md5 \ --define _binary_filedigest_algorithm md5 endif ifeq ($(DISTVAL),9) RPM_DEFINES := $(RPM_DEFINES) \ --define _source_filedigest_algorithm md5 \ --define _binary_filedigest_algorithm md5 endif this will allow you to create useable srpms with make srpm for scratch building Dennis signature.asc Description: This is a digitally signed message part. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: kojira repo generation
On Thursday 26 February 2009 11:51:14 am Thomas Hatch wrote: I keep having problems with it telling me the system is locked until I run a restart, but service kojid status keeps returning the same error ; The URL for the xmlrpc server server=http://sunlight.pp.bcinfra.net/kojihub user=koji.bcinfra.net do you have this same user defined elsewhere? only one session per uer can be active. Dennis signature.asc Description: This is a digitally signed message part. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: attribute errors when koji login
On Wednesday 25 February 2009 05:24:45 am 陈鲍孜 wrote: Mike Bonnet wrote: What version of Koji are you using? That error has been fixed in Koji git for a while, and is available in the latest release, Koji 1.3.1. You'll need to run it on CentOS 5. I'm using those koji-1.2.6-1.el5.noarch.rpm koji-utils-1.2.6-1.el5.noarch.rpm koji-builder-1.2.6-1.el5.noarch.rpm koji-web-1.2.6-1.el5.noarch.rpm koji-hub-1.2.6-1.el5.noarch.rpm from EPEL repository on CentOS 5.2. Maybe I should try a newer one. 1.3.1 is in EPEL testing. I would recommend that you use it instead. Dennis -- 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
On Wednesday 04 February 2009 09:29:54 pm 陈鲍孜 wrote: Hello, I was trying to distribute koji with the rpms from EPEL on CentOS following the instructions of ServerHowTo. It seems I've made some mistakes that it's said kojid dead but subsys locked while I was checking kojid status after having it started successfully. what do you get when you run /usr/sbin/kojid -f -c /etc/kojid/kojid.conf BTW, I was a little confused about how to run a koji environment with the ServerHowTo wiki, due to the relationship of those configurations. which part was confusing? the howto doesn't really say where to run each piece because each pieces can be run on separate and multiple boxes. for instance fedora runs 2 hubs. multiple builders, a single db box and a single box for serving up the packages. Dennis -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: OpenSuSE Buildsystem
On Tuesday 16 December 2008 10:48:48 am Mike McGrath wrote: I've been talking with some of the SuSE guys and we agree there's some overlap or at least coordination between their buildsystem and ours. The first obvious low hanging fruit is common macros. For those who wonder why would we help OpenSuSE? the answer is common goals, and better user experiences. The problem is time and coordination. So on a whim I thought I'd send this email out. Do we have any contributors out there who are both members of Fedora and SuSE who would be willing to lead this charge, find similarities and places for coordination? I think that common macros needs to be solved at rpm.org level. not a buildsystem level. koji has no say in any of the macros it uses what is defined inside the distro. the macros fedora uses are defined in rpm and redhat- rpm-config, the disttag macro is defined in fedora-release. I see great benefit to everyone by having that problem solved at the rpm.org level. it will make it much easier to pickup packages and fixes cross distro. that is not a bad thing. especially for ISV's and upstreams supporting all distros they only need to do the work once and build everywhere. Working directly with them to fix issues for there buildsystem however I feel causes some conflicts. namely it legitimises the use of there buildsystem for building fedora/RHEL packages. I know people use it and will continue to do so. but I would ask why? is there some service that fedora could provide and is not? is it because you can be lazy and sloppy in the packaging and it lets you? is it just being able to do it in a single place? We do need to get out of the business of running two buildsystems. we really do need to be able to build EPEL in koji. I have scheduled a koji hackfest for fudcon. so if your there and interested then come help. there is always #koji on freenode for discussion on koji, so if you cant make it in person you can be there virtually :) Dennis -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
[PATCH] pungi handling of sparc
the attached patch makes the calls to anaconda include all sparc 32 bit arches
when building a sparc tree.
Without change the treearch to sparcv9v we would get the small handful of
sparc packages and noarch. all the sparcv9 and sparcv9v woule be excluded.
this patch is against master. there is one for F-9 in fedora cvs
Dennis
From a11b23bfbe4e517f2a9993c59ee067e68130a46e Mon Sep 17 00:00:00 2001
From: Dennis Gilmore [EMAIL PROTECTED]
Date: Wed, 15 Oct 2008 20:41:46 -0500
Subject: [PATCH] add handling so sparc arch gets handled correctly, we need to ensure we include all 32 bit arches
---
src/pypungi/__init__.py | 21 ++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/src/pypungi/__init__.py b/src/pypungi/__init__.py
index 480cbf0..025e1ce 100644
--- a/src/pypungi/__init__.py
+++ b/src/pypungi/__init__.py
@@ -746,13 +746,18 @@ class Pungi(pypungi.PungiBase):
def doPackageorder(self):
Run anaconda-runtime's pkgorder on the tree, used for splitting media.
+if self.config.get('default', 'arch') == sparc:
+treearch = sparcv9v
+else:
+treearch = self.config.get('default', 'arch')
+self.logger.info(Setting treearch to %s % treearch)
pkgorderfile = open(os.path.join(self.workdir, 'pkgorder-%s' % self.config.get('default', 'arch')), 'w')
# setup the command
pkgorder = ['/usr/bin/pkgorder']
#pkgorder.append('TMPDIR=%s' % self.workdir)
pkgorder.append(self.topdir)
-pkgorder.append(self.config.get('default', 'arch'))
+pkgorder.append(treearch)
pkgorder.append(self.config.get('default', 'product_path'))
# run the command
@@ -821,9 +826,14 @@ class Pungi(pypungi.PungiBase):
Use anaconda-runtime's splittree to split the tree into appropriate
sized chunks.
+if self.config.get('default', 'arch') == sparc:
+treearch = sparcv9v
+else:
+treearch = self.config.get('default', 'arch')
+self.logger.info(Setting treearch to %s % treearch)
timber = splittree.Timber()
-timber.arch = self.config.get('default', 'arch')
+timber.arch = treearch
timber.target_size = self.config.getfloat('default', 'cdsize') * 1024 * 1024
timber.total_discs = self.config.getint('default', 'discs')
timber.bin_discs = self.config.getint('default', 'discs')
@@ -846,9 +856,14 @@ class Pungi(pypungi.PungiBase):
Use anaconda-runtime's splittree to split the srpms into appropriate
sized chunks.
+if self.config.get('default', 'arch') == sparc:
+treearch = sparcv9v
+else:
+treearch = self.config.get('default', 'arch')
+self.logger.info(Setting treearch to %s % treearch)
timber = splittree.Timber()
-timber.arch = self.config.get('default', 'arch')
+timber.arch = treearch
#timber.total_discs = self.config.getint('default', 'discs')
#timber.bin_discs = self.config.getint('default', 'discs')
timber.src_discs = self.config.getint('default', 'discs')
--
1.6.0.1
signature.asc
Description: This is a digitally signed message part.
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: koji-1.2.6
On Wednesday 03 September 2008 09:48:28 am Doug Ledford wrote: On Mon, 2008-08-25 at 19:28 -0400, Mike McLean wrote: It's been a long time since we posted a fresh tarball, so I just tagged and posted 1.2.6. Following is a summary of changes since 1.2.5. A couple of them /may/ cause some slight upgrade issues. Any idea when updated packages for koji will hit the shelves? as soon as updates go out. its in EPEL-testing and rawhide now. updates are queued for Fedora-8 and Fedora-9 Dennis signature.asc Description: This is a digitally signed message part. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: bodhi abuse?
On Saturday 30 August 2008 06:15:05 am Michael Schwendt wrote: https://admin.fedoraproject.org/updates/phpMyAdmin-2.11.9-1.fc8 [and several other updates] +1 dcottle - 2008-08-30 08:09:35 +1 acottle - 2008-08-30 08:11:54 +1 auscity - 2008-08-30 08:21:14 https://admin.fedoraproject.org/accounts/user/view/auscity (David Cottle) https://admin.fedoraproject.org/accounts/user/view/dcottle (David Cottle, email in aus-city domain) https://admin.fedoraproject.org/accounts/user/view/acottle Same name and domain in email address. If this is an attempt at trying to autopush updates faster via positive karma, stop this, please. this should be taken up with FESCo not here. since the request was to stable it was a pointless attempt.but it should be looked at Dennis signature.asc Description: This is a digitally signed message part. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
[PATCH] make authtype a config option
the attached patch adds a config option that can be in a config file or on the command line forcing the use of one authentication type. it is useful if a hub supports more than one authentication type. or using different hubs that support different authentications methods. Ive tested with noauth, kerberos, and ssl. Dennis From 0e56c86e70755733985c92619a9b5c03019d0353 Mon Sep 17 00:00:00 2001 From: Dennis Gilmore [EMAIL PROTECTED] Date: Mon, 11 Aug 2008 22:52:57 -0500 Subject: [PATCH] add a command line switch and config option to set the auth type options are : noauth password ssl and kerberos --authtype is the switch or authtype = line in config file --- cli/koji | 14 -- 1 files changed, 8 insertions(+), 6 deletions(-) diff --git a/cli/koji b/cli/koji index 56edb29..af91c1d 100755 --- a/cli/koji +++ b/cli/koji @@ -93,6 +93,7 @@ def get_options(): help=_(do not authenticate)) parser.add_option(--force-auth, action=store_true, default=False, help=_(authenticate even for read-only operations)) +parser.add_option(--authtype, help=_(force use of a type of authentication, options: noauth, ssl, password, or kerberos)) parser.add_option(-d, --debug, action=store_true, default=False, help=_(show debug output)) parser.add_option(--debug-xmlrpc, action=store_true, default=False, @@ -141,7 +142,8 @@ def get_options(): 'topdir' : '/mnt/koji', 'cert': '~/.koji/client.crt', 'ca': '~/.koji/clientca.crt', -'serverca': '~/.koji/serverca.crt' +'serverca': '~/.koji/serverca.crt', +'authtype': None } # grab settings from /etc/koji.conf first, and allow them to be # overridden by user config @@ -4046,16 +4048,16 @@ def has_krb_creds(): def activate_session(session): Test and login the session is applicable global options -if options.noauth: +if options.authtype == noauth or options.noauth: #skip authentication pass -elif os.path.isfile(options.cert): +elif options.authtype == ssl or os.path.isfile(options.cert) and options.authtype is None: # authenticate using SSL client cert session.ssl_login(options.cert, options.ca, options.serverca, proxyuser=options.runas) -elif options.user: +elif options.authtype == password or options.user and options.authtype is None: # authenticate using user/password session.login() -elif has_krb_creds(): +elif options.authtype == kerberos or has_krb_creds() and options.authtype is None: try: if options.keytab and options.principal: session.krb_login(principal=options.principal, keytab=options.keytab, proxyuser=options.runas) @@ -4065,7 +4067,7 @@ def activate_session(session): error(_(Kerberos authentication failed: %s (%s)) % (e.args[1], e.args[0])) except socket.error, e: warn(_(Could not connect to Kerberos authentication service: %s) % e.args[1]) -if not options.noauth and not session.logged_in: +if not options.noauth and options.authtype != noauth and not session.logged_in: error(_(Unable to log in, no authentication methods available)) ensure_connection(session) if options.debug: -- 1.5.6.4 -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [PATCHES] Makefile.common speedups
On Wednesday 30 July 2008, Adam Jackson wrote: Attached are two (orthogonal) patches to make evaluation of Makefile.common a bit faster. The first one is possibly contentious. Currently, early-branching works by checking for the existence of the other branch, by using 'cvs rlog'. That kinda sucks, because it means you can't do 'make local' while disconnected, and even when connected it's not fast. The patch changes it to look for the package's name in a new file, common/early-branched-packages. By keeping that file together with Makefile.common we get pretty much the behaviour we're used to: when build targets change, you have to update common/. Note that if we apply this patch we will also need to create that (empty) file. This would change the cvsadmin procedure for early branching, but hopefully not by a burdensome amount. The second one is just a refactoring to only ask rpm for %VERSION and %RELEASE once. In principle, for packages that overrode both VERSION and RELEASE in their Makefile, this would actually make things slower, since now you'd be forcing rpm to run. According to my pkgcvs checkout, no such packages exist. Tested locally on a 3.2GHz P4. 'time make' baseline was 1.3 seconds. First patch dropped that to about 0.6 seconds. Second patch on top of that dropped down to about 0.38 seconds. - ajax ive applied the second patch. I think id rather us comment out the early branching check all together when we don't need it. we probably should add some checks to make build and tag so that it does a cvs up on the common dir. as it can be an issue when they are out of date. -- Dennis Gilmore signature.asc Description: This is a digitally signed message part. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [PATCHES] Makefile.common speedups
On Wednesday 30 July 2008, Adam Jackson wrote: On Wed, 2008-07-30 at 10:26 -0700, Toshio Kuratomi wrote: Adam Jackson wrote: Attached are two (orthogonal) patches to make evaluation of Makefile.common a bit faster. The first one is possibly contentious. Currently, early-branching works by checking for the existence of the other branch, by using 'cvs rlog'. That kinda sucks, because it means you can't do 'make local' while disconnected, and even when connected it's not fast. The patch changes it to look for the package's name in a new file, common/early-branched-packages. By keeping that file together with Makefile.common we get pretty much the behaviour we're used to: when build targets change, you have to update common/. Note that if we apply this patch we will also need to create that (empty) file. This would change the cvsadmin procedure for early branching, but hopefully not by a burdensome amount. I'm against this one as it moves a kludge from Makefile.common into the scripts that handle branching. Can we achieve the same thing by keeping the information in the devel branch? For instance, each of the other branches has a branch file with the branch name inside. If devel did the same, could we alleviate this problem? Sure. Makefile.common could parse the 'branch' file even for devel/, and the magic word early or rawhide or something would mean early branch if that's an option, otherwise normal rawhide behaviour. I don't have strong feelings about where the early-branch indicator lives, as long as it's something I can know without asking the CVS server. - ajax cat F-9/branch F-9 it should reference the line in branches that tells the Makefiles where to build. this would require changes in the mass-branching, branching scripts to make sure its right. but it should be workable. so when we start early branching we will put F-11 in the branch file and add to branches in common for knowing how to deal with F-11 -- Dennis Gilmore signature.asc Description: This is a digitally signed message part. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: possible koji logo
On Monday 23 June 2008, Mike McLean wrote: Using the unicode character as a base, I drew a set of paths in the gimp and painted along them using one of the calligraphy brushes. I turned on the 'jitter' option on the paintbrush tool to give it a more natural look. This png shows this path tracing side-by-side with the unicode character at the same scale. http://people.redhat.com/mikem/software/koji-icon-path.png If you want the gimp file with the path data, it is here: http://people.redhat.com/mikem/software/koji-icon-path.xcf.bz2 Having the paths enables us to scale the icon very well and make variations more easily. Anyway, I think it might need a few tweaks, but overall I think I like it. What do folks think? I like it, It looks nice and clean. maybe we can get Mo to touch it up? -- Dennis Gilmore signature.asc Description: This is a digitally signed message part. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: corrupt rpmdb in mock-chroot
On Monday 02 June 2008, Paul B Schroeder wrote: On Sat, 2008-05-31 at 22:16 -0400, Jon Stanley wrote: On Sat, May 31, 2008 at 7:04 PM, Paul B Schroeder [EMAIL PROTECTED] wrote: Rebuilding the rpm database seems to fix this, but it's a pain to be sure. Any ideas as to why I'm seeing this corruption when creating an i386 mock chroot from a x86_64 system? This is normal and expected. You created the rpmdb with x86_64 rpm, and are accessing it with i386 rpm. The Berkeley DB format is different based on the arch of the creating machine, therefore generates the database differently on the two platforms. If I plan on doing anything in a chroot (especially a non-native arch one) other than building a SRPM, the first thing that happens is to rm -f /var/lib/rpm/__db*. Don't worry, this got me the first time too (and is fatal to a pungi compose) :) Ah.. I see.. I would think there would be some way to tell it to create the DB in i386 format though? Is there an environment variable or something that can be set? No, the hosts rpm is used to populate the chroot. when you enter the chroot you can delete /var/lib/rpm/__db* and things will work. You get the same issues with building say F-7 chroots on a F-9 host where the chroot has a different version of the the database than the host. Dennis signature.asc Description: This is a digitally signed message part. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: corrupt rpmdb in mock-chroot
On Monday 02 June 2008, Paul B Schroeder wrote: On Mon, 2008-06-02 at 08:25 -0500, Dennis Gilmore wrote: On Monday 02 June 2008, Paul B Schroeder wrote: On Sat, 2008-05-31 at 22:16 -0400, Jon Stanley wrote: On Sat, May 31, 2008 at 7:04 PM, Paul B Schroeder [EMAIL PROTECTED] wrote: Rebuilding the rpm database seems to fix this, but it's a pain to be sure. Any ideas as to why I'm seeing this corruption when creating an i386 mock chroot from a x86_64 system? This is normal and expected. You created the rpmdb with x86_64 rpm, and are accessing it with i386 rpm. The Berkeley DB format is different based on the arch of the creating machine, therefore generates the database differently on the two platforms. If I plan on doing anything in a chroot (especially a non-native arch one) other than building a SRPM, the first thing that happens is to rm -f /var/lib/rpm/__db*. Don't worry, this got me the first time too (and is fatal to a pungi compose) :) Ah.. I see.. I would think there would be some way to tell it to create the DB in i386 format though? Is there an environment variable or something that can be set? No, the hosts rpm is used to populate the chroot. when you enter the chroot you can delete /var/lib/rpm/__db* and things will work. You get the same issues with building say F-7 chroots on a F-9 host where the chroot has a different version of the the database than the host. I understand how it's working. (Although, I didn't know Berkely DB had diff formats for diff archs beforehand) But I was hoping there might be a way (in my Makefiles) to tell my x86_64 host's rpm to always operate in i386 mode. I can live with it, but I am setting up a build environment for other (read less Linux literate) folks to use. I'd like to head off any forthcoming confusion if possible. Cheers...Paul... Please dont CC me on list email just reply to list you could try run setarch i386 before the mock command. Dennis signature.asc Description: This is a digitally signed message part. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Makefile.common change
The way we currently check for branches is broken at release time. everything that was tagged in devel that was branched for F-9 when you try and build in koji gets a disttag of .fc10 and fails to build due to a mismatch. this has been a minor issue in the past. but it is a big issue for secondary arch rampup. Makefile.common checked for the existence of a branch file which devel does not have. it is added at branch time. long term we probably need to add some logic so that we always have a branch file and check it and fall back to this method if its not there. it will help with always being able to reproduce a srpm. Since this is somewhat invasive i wanted to run it by people first. it worked ok in my testing. Dennis ? Makefile.common.branch Index: Makefile.common === RCS file: /cvs/pkgs/common/Makefile.common,v retrieving revision 1.94 diff -u -r1.94 Makefile.common --- Makefile.common 22 Apr 2008 15:44:53 - 1.94 +++ Makefile.common 24 Apr 2008 02:30:13 - @@ -19,7 +19,7 @@ ifndef HEAD_BRANCH HEAD_BRANCH := devel endif -BRANCH:=$(shell [ -f branch ] cat branch || echo $(HEAD_BRANCH)) +BRANCH:=$(lastword $(shell pwd| cut -d/ --output-delimiter= -f2-)) # check to see if this is an early branched package; we should make this more # generic in the future ifeq ($(BRANCH),devel) signature.asc Description: This is a digitally signed message part. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Makefile.common change
On Wednesday 23 April 2008, Bill Nottingham wrote:
Dennis Gilmore ([EMAIL PROTECTED]) said:
? Makefile.common.branch
Index: Makefile.common
===
RCS file: /cvs/pkgs/common/Makefile.common,v
retrieving revision 1.94
diff -u -r1.94 Makefile.common
--- Makefile.common 22 Apr 2008 15:44:53 - 1.94
+++ Makefile.common 24 Apr 2008 02:30:13 -
@@ -19,7 +19,7 @@
ifndef HEAD_BRANCH
HEAD_BRANCH := devel
endif
-BRANCH:=$(shell [ -f branch ] cat branch || echo $(HEAD_BRANCH))
+BRANCH:=$(lastword $(shell pwd| cut -d/ --output-delimiter= -f2-))
# check to see if this is an early branched package; we should make this
more # generic in the future
ifeq ($(BRANCH),devel)
Seems good. Of course, there's 5000 ways to do it, with cut, awk,
${foo##*/}, etc.
Thanks ive applied
Dennis
signature.asc
Description: This is a digitally signed message part.
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Koji hidden packages proposal
On Saturday 15 March 2008, Mike Bonnet wrote: On Fri, 2008-03-14 at 19:55 -0500, Dennis Gilmore wrote: On Friday 14 March 2008, Mike Bonnet wrote: I've written up a brief proposal about how hidden packages may be supported in Koji. The objective of this is to enable building EPEL packages in Koji. I wrote this up fairly quickly, and I'm sure I haven't thought through all the issues, but I wanted to get the ball rolling. Let me know if you have any questions/comments/ideas/issues relating to this proposal. http://people.redhat.com/mikeb/koji/koji-hidden-packages-proposal.html Thanks, Mike the tree will have to be nothing like /mnt/koji/packages instead it will have to be like http://download.fedora.redhat.com/pub/fedora/linux/ so that you can use rsync and repo mirroring tools to sync the content and keep trees in sync. ill leave it up to Seth to explain more but hit micro repository option he is working on would allow us to pull the existing repodata intothe new repodata. I'm not really sure what you're talking about. *No one* will be mirroring the hidden packages in the case we're talking about (building EPEL in Koji), these will be RHEL binaries, and only available to the builders. 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. We really only need to have a command that can suck the repodata into the database. so we know about the packages. We have a command that can suck data about packages in to the database. It's koji import. The proposal is designed to work within the framework of that we already have in Koji, to try to minimize the number of changes and thus the time it'll take to implement. sure koji import --repodata --url=http|ftp|file://host/path/to/repodata The micro repository option Seth has talked about sounds interesting, but it doesn't really help with the issue of making packages available to Koji builders without making them available to the world. sure it does, we have an internal only tree thats on the phx internal network and not available outside of phx, just as we do now. Dennis signature.asc Description: This is a digitally signed message part. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Koji hidden packages proposal
On Friday 14 March 2008, Mike Bonnet wrote: I've written up a brief proposal about how hidden packages may be supported in Koji. The objective of this is to enable building EPEL packages in Koji. I wrote this up fairly quickly, and I'm sure I haven't thought through all the issues, but I wanted to get the ball rolling. Let me know if you have any questions/comments/ideas/issues relating to this proposal. http://people.redhat.com/mikeb/koji/koji-hidden-packages-proposal.html Thanks, Mike the tree will have to be nothing like /mnt/koji/packages instead it will have to be like http://download.fedora.redhat.com/pub/fedora/linux/ so that you can use rsync and repo mirroring tools to sync the content and keep trees in sync. ill leave it up to Seth to explain more but hit micro repository option he is working on would allow us to pull the existing repodata intothe new repodata. We really only need to have a command that can suck the repodata into the database. so we know about the packages. Dennis signature.asc Description: This is a digitally signed message part. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: rebuilding from old cvs tags
On Tuesday 26 February 2008, Mike McLean wrote: I ran into an interesting problem while replicating some older Fedora builds in a test environment. Consider this build: http://koji.fedoraproject.org/koji/buildinfo?buildID=6144 It was built by task 1648 using this cvs url: cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/sparse/devel#sparse-0_3-1_fc7 The problem is that if you rebuild this now, you get DIST=fc9, because devel has moved on. In my case, I am replicating the buildroot, which includes the package that provides the original DIST=fc7. This leads to a mismatch. Koji thinks it is building sparse-0.3-1.fc9, but the actual result is sparse-0.3-1.fc7. The build completes but import fails. I'm trying to reproduce the build as closely as possible, so I want .fc7, not .fc9. I ran into the exact same issue when i was doing the same thing. It occurred to me that Makefile.common could be smarter about this. When you checkout a specific revision with cvs, that revision is noted in CVS/Tag. It would be possible (though perhaps messy) for Makefile.common to note this and behave a little differently. we probably want to keep in cvs the version of common that was in the tree at tag time. then checkout the same version of common then it will do the right thing (tm) Why? Better repeatability. If you checkout a specific revision from a time when dist has a different value, you probably ought to be using that dist and not the current one. I suppose the real problem is that although we're building from a specific revision of the main checkout, we're always using the HEAD of common. Solving that even more of a mess though (and even if we do, we still have a whole bunch of builds from unrecorded revisions of common in the system). So what do folks think? Am I crazy? Would a Makefile.common patch for this be welcome? A patch would be welcome for it. its something i've been meaning to look at for awhile now. Just to make sure that you can always do a make srpm and get a srpm out that matches. Ive considered the idea of having a web app to make srpms on demand for people also. It would most likely be needed there also. But it doesnt help with the historical data we dont have. Dennis signature.asc Description: This is a digitally signed message part. -- 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?)
On Sunday 20 January 2008, Dennis Gilmore wrote:
On Sunday 20 January 2008, Jesse Keating wrote:
On Sun, 20 Jan 2008 20:32:46 -0600
Dennis Gilmore [EMAIL PROTECTED] 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
https://fedorahosted.org/koji/changeset/6feae640c291ae24de8e855b8564ff786
52 7dcb9 ? Where there others as of yet not committed?
https://www.redhat.com/archives/fedora-buildsys-list/2008-January/msg00045.
html
that one is not yet commited. It adds the config option so we dont spam
maintainers with a bunch of email for successful builds.
Dennis
here is the updated patch. if its too late thats ok
Dennis
From 61b4c4f156378d8feee9ff7af86c8d123f17725b Mon Sep 17 00:00:00 2001
From: Dennis Gilmore [EMAIL PROTECTED]
Date: Mon, 14 Jan 2008 22:00:43 -0600
Subject: [PATCH] make a configurable option to send email for success or not
---
hub/httpd.conf |1 +
hub/kojihub.py | 16 +---
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/hub/httpd.conf b/hub/httpd.conf
index e4acd64..5d3f5e1 100644
--- a/hub/httpd.conf
+++ b/hub/httpd.conf
@@ -32,6 +32,7 @@ Alias /kojihub /usr/share/koji-hub/XMLRPC
# The domain name that will be appended to Koji usernames
# when creating email notifications
PythonOption EmailDomain example.com
+PythonOption NotifyOnSuccess False
# PythonOption KojiDebug On
# PythonOption KojiTraceback extended
# sending tracebacks to the client isn't very helpful for debugging xmlrpc
diff --git a/hub/kojihub.py b/hub/kojihub.py
index 9a75552..5a4cfc7 100644
--- a/hub/kojihub.py
+++ b/hub/kojihub.py
@@ -3551,13 +3551,15 @@ def get_notification_recipients(build, tag_id, state):
emails = [result[0] for result in _fetchMulti(query, locals())]
email_domain = context.opts['EmailDomain']
-
-# user who submitted the build
-emails.append('[EMAIL PROTECTED]' % (build['owner_name'], email_domain))
-
-packages = readPackageList(pkgID=package_id, tagID=tag_id, inherit=True)
-# owner of the package in this tag, following inheritance
-emails.append('[EMAIL PROTECTED]' % (packages[package_id]['owner_name'], email_domain))
+notifyonsuccess = context.opts['NotifyOnSuccess']
+
+if notfyonsuccess == 'True' or state != koji.BUILD_STATES['COMPLETE']:
+# user who submitted the build
+emails.append('[EMAIL PROTECTED]' % (build['owner_name'], email_domain))
+
+packages = readPackageList(pkgID=package_id, tagID=tag_id, inherit=True)
+# owner of the package in this tag, following inheritance
+emails.append('[EMAIL PROTECTED]' % (packages[package_id]['owner_name'], email_domain))
emails_uniq = dict(zip(emails, [1] * len(emails))).keys()
return emails_uniq
--
1.5.3.8
signature.asc
Description: This is a digitally signed message part.
--
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?)
On Sunday 20 January 2008, Jesse Keating wrote: I'd like to do a new upstream release of koji soon, to take advantage of createrepo improvements and to have a release with some of the bugfixes that I've found since our refresh to RHEL5/new mock. The builders are locally patched for the bugfixes but I'd rather have them in a package. Any objections to doing a release next week and scheduling an evening to roll out upgrades? A small outage will be needed on the hub, and then the builders can have a rolling outage. There are no significant changes that would require much coordination. 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 Dennis signature.asc Description: This is a digitally signed message part. -- 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?)
On Sunday 20 January 2008, Jesse Keating wrote: On Sun, 20 Jan 2008 20:32:46 -0600 Dennis Gilmore [EMAIL PROTECTED] 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 https://fedorahosted.org/koji/changeset/6feae640c291ae24de8e855b8564ff78652 7dcb9 ? Where there others as of yet not committed? https://www.redhat.com/archives/fedora-buildsys-list/2008-January/msg00045.html that one is not yet commited. It adds the config option so we dont spam maintainers with a bunch of email for successful builds. Dennis signature.asc Description: This is a digitally signed message part. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [PATCH] koji make sending email on success to owner configurable
On Monday 14 January 2008, Dennis Gilmore wrote:
the attached patch makes it configurable to send email to the owner of a
package and person submitting the job. This is needed for secondary arches
so that you dont get 6 emails per build.
Dennis
this patch fixes a typo in the original.
Dennis
From 61b4c4f156378d8feee9ff7af86c8d123f17725b Mon Sep 17 00:00:00 2001
From: Dennis Gilmore [EMAIL PROTECTED]
Date: Mon, 14 Jan 2008 22:00:43 -0600
Subject: [PATCH] make a configurable option to send email for success or not
---
hub/httpd.conf |1 +
hub/kojihub.py | 16 +---
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/hub/httpd.conf b/hub/httpd.conf
index e4acd64..5d3f5e1 100644
--- a/hub/httpd.conf
+++ b/hub/httpd.conf
@@ -32,6 +32,7 @@ Alias /kojihub /usr/share/koji-hub/XMLRPC
# The domain name that will be appended to Koji usernames
# when creating email notifications
PythonOption EmailDomain example.com
+PythonOption EmailOwner False
# PythonOption KojiDebug On
# PythonOption KojiTraceback extended
# sending tracebacks to the client isn't very helpful for debugging xmlrpc
diff --git a/hub/kojihub.py b/hub/kojihub.py
index 9a75552..5a4cfc7 100644
--- a/hub/kojihub.py
+++ b/hub/kojihub.py
@@ -3551,13 +3551,15 @@ def get_notification_recipients(build, tag_id, state):
emails = [result[0] for result in _fetchMulti(query, locals())]
email_domain = context.opts['EmailDomain']
-
-# user who submitted the build
-emails.append('[EMAIL PROTECTED]' % (build['owner_name'], email_domain))
-
-packages = readPackageList(pkgID=package_id, tagID=tag_id, inherit=True)
-# owner of the package in this tag, following inheritance
-emails.append('[EMAIL PROTECTED]' % (packages[package_id]['owner_name'], email_domain))
+email_owner = context.opts['EmailOwner']
+
+if email_owner is True or state != koji.BUILD_STATES['COMPLETE']:
+# user who submitted the build
+emails.append('[EMAIL PROTECTED]' % (build['owner_name'], email_domain))
+
+packages = readPackageList(pkgID=package_id, tagID=tag_id, inherit=True)
+# owner of the package in this tag, following inheritance
+emails.append('[EMAIL PROTECTED]' % (packages[package_id]['owner_name'], email_domain))
emails_uniq = dict(zip(emails, [1] * len(emails))).keys()
return emails_uniq
--
1.5.3.8
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [PATCH] koji create repo when building only for a subarch
On Friday 11 January 2008, Dennis Gilmore wrote:
The attached patch has koji build repos when you are building only for a
non-canonical arch. this would allow someone to shadowbuild fedora and
build for i686 for instance. they would get a 32 bit repo. I dont see
any issues with this unless you try to build for multiple sub-arches but
that is no different to what we have now. with this patch you will not get
ppc repos for instance if you are only building i386 but happen to have
ppc packages in the tree
Dennis
Here is an updated patch that will work on python-2.3 this is against head
Dennis
From 00c28c59e206f6415b53994d1d92c4a1515b69e3 Mon Sep 17 00:00:00 2001
From: Dennis Gilmore [EMAIL PROTECTED]
Date: Mon, 14 Jan 2008 21:11:05 -0600
Subject: [PATCH] update repo creation for sub arches so that it works on python-2.3
---
hub/kojihub.py |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/hub/kojihub.py b/hub/kojihub.py
index aa4b221..9a75552 100644
--- a/hub/kojihub.py
+++ b/hub/kojihub.py
@@ -1680,10 +1680,13 @@ def repo_init(tag, with_src=False, with_debuginfo=False):
state = koji.REPO_INIT
tinfo = get_tag(tag, strict=True)
tag_id = tinfo['id']
+repo_arches = []
if tinfo['arches']:
tag_arches = tinfo['arches'].split()
-else:
-tag_arches = []
+for arch in tag_arches:
+canonArch = koji.canonArch(arch)
+if canonArch not in repo_arches:
+repo_arches.append(canonArch)
repo_id = _singleValue(SELECT nextval('repo_id_seq'))
event_id = _singleValue(SELECT get_event())
q = INSERT INTO repo(id, create_event, tag_id, state)
@@ -1708,7 +1711,7 @@ def repo_init(tag, with_src=False, with_debuginfo=False):
continue
elif arch == 'noarch':
pass
-elif repoarch not in tag_arches:
+elif repoarch not in repo_arches:
# Do not create a repo for arches not in the arch list for this tag
continue
build = builds[rpminfo['build_id']]
--
1.5.3.8
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
[PATCH] koji make sending email on success to owner configurable
the attached patch makes it configurable to send email to the owner of a
package and person submitting the job. This is needed for secondary arches
so that you dont get 6 emails per build.
Dennis
From 61b4c4f156378d8feee9ff7af86c8d123f17725b Mon Sep 17 00:00:00 2001
From: Dennis Gilmore [EMAIL PROTECTED]
Date: Mon, 14 Jan 2008 22:00:43 -0600
Subject: [PATCH] make a configurable option to send email for success or not
---
hub/httpd.conf |1 +
hub/kojihub.py | 16 +---
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/hub/httpd.conf b/hub/httpd.conf
index e4acd64..5d3f5e1 100644
--- a/hub/httpd.conf
+++ b/hub/httpd.conf
@@ -32,6 +32,7 @@ Alias /kojihub /usr/share/koji-hub/XMLRPC
# The domain name that will be appended to Koji usernames
# when creating email notifications
PythonOption EmailDomain example.com
+PythonOption EmailOwner False
# PythonOption KojiDebug On
# PythonOption KojiTraceback extended
# sending tracebacks to the client isn't very helpful for debugging xmlrpc
diff --git a/hub/kojihub.py b/hub/kojihub.py
index 9a75552..5a4cfc7 100644
--- a/hub/kojihub.py
+++ b/hub/kojihub.py
@@ -3551,13 +3551,15 @@ def get_notification_recipients(build, tag_id, state):
emails = [result[0] for result in _fetchMulti(query, locals())]
email_domain = context.opts['EmailDomain']
-
-# user who submitted the build
-emails.append('[EMAIL PROTECTED]' % (build['owner_name'], email_domain))
-
-packages = readPackageList(pkgID=package_id, tagID=tag_id, inherit=True)
-# owner of the package in this tag, following inheritance
-emails.append('[EMAIL PROTECTED]' % (packages[package_id]['owner_name'], email_domain))
+email_owner = context.opts['EmailOwner']
+
+if EmailOwner is True or state != koji.BUILD_STATES['COMPLETE']:
+# user who submitted the build
+emails.append('[EMAIL PROTECTED]' % (build['owner_name'], email_domain))
+
+packages = readPackageList(pkgID=package_id, tagID=tag_id, inherit=True)
+# owner of the package in this tag, following inheritance
+emails.append('[EMAIL PROTECTED]' % (packages[package_id]['owner_name'], email_domain))
emails_uniq = dict(zip(emails, [1] * len(emails))).keys()
return emails_uniq
--
1.5.3.8
signature.asc
Description: This is a digitally signed message part.
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
[PATCH] koji create repo when building only for a subarch
The attached patch has koji build repos when you are building only for a
non-canonical arch. this would allow someone to shadowbuild fedora and build
for i686 for instance. they would get a 32 bit repo. I dont see any issues
with this unless you try to build for multiple sub-arches but that is no
different to what we have now. with this patch you will not get ppc repos
for instance if you are only building i386 but happen to have ppc packages
in the tree
Dennis
diff --git a/hub/kojihub.py b/hub/kojihub.py
index c02596b..4b4d62a 100644
--- a/hub/kojihub.py
+++ b/hub/kojihub.py
@@ -1682,6 +1682,9 @@ def repo_init(tag, with_src=False, with_debuginfo=False):
tag_id = tinfo['id']
if tinfo['arches']:
tag_arches = tinfo['arches'].split()
+set(repo_arches)
+for arch in tag_arches:
+repo_archs.add(koji.canonArch(arch))
else:
tag_arches = []
repo_id = _singleValue(SELECT nextval('repo_id_seq'))
@@ -1708,7 +1711,7 @@ def repo_init(tag, with_src=False, with_debuginfo=False):
continue
elif arch == 'noarch':
pass
-elif repoarch not in tag_arches:
+elif repoarch not in repo_arches:
# Do not create a repo for arches not in the arch list for this tag
continue
build = builds[rpminfo['build_id']]
signature.asc
Description: This is a digitally signed message part.
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: koji initialization, docs
On Tuesday 11 September 2007 9:36:31 am Enrico Scholz wrote: rob myers [EMAIL PROTECTED] writes: from what i remember, the first step is to import rpms for the distribution you are building against. Can be avoided by applying https://www.redhat.com/archives/fedora-buildsys-list/2007-May/msg00023.html and using an external repository. Enrico Which breaks many things in koji. such as reproducability. koji keeps track of and holds all rpms that are used in buildroots. Dennis -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [PATCH] Makefile.common: add scratch build targets
On Wednesday 11 July 2007 10:22:15 am Till Maas wrote: Aloas, the attached patch adds support for scratch builds to Makefile.common: scratch-build Request scratch build of fcgi-2_4_0-2_fc8 for dist-f8 scratch-build-archs Request scratch build of fcgi-2_4_0-2_fc8 for dist-f8 and archs archs examples: make scratch-build-i386,ppc64 make scratch-build-x86_64 Regards, Till Rather than have a check for koji's existence in each target, i would perfer a target to check for koji and have the makefile call that. Then if the location to get information changes or we switch out koji and go to something else we only need to update information in one place. Dennis -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: plague-client list
try plague-client list status needsign uid_gt 22000 the problem is the command is returning too much data. On Saturday 25 November 2006 11:28 am, Michael Schwendt wrote: $ plague-client list Error: an error ocurred communicating with the server. 'Fault 1: 'pg.DatabaseError:error \'ERROR: expression too complex\nDETAIL: Nesting depth exceeds maximum expression depth 1.\nHINT: Increase the configuration parameter max_expr_depth.\n\' in \'SELECT jobid, parent_uid, starttime, endtime, arch, builder_addr, status, builder_status FROM archjobs WHERE parent_uid=5 ---snip--- (400K of parent_uid=...) $ plague-client list status needsign (same here) $ plague-client list result success (same here) $ plague-client list status failed Error: connection to the server timed out. '(110, 'Operation timed out.')' $ plague-client list status building (same here) $ plague-client list email myemailaddress (works) -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -- Dennis Gilmore, RHCE Proud Australian -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: buildsys misconfigured
On Saturday 25 November 2006 9:22 am, Dennis Gilmore wrote: Once upon a time Saturday 25 November 2006 9:10 am, Michael Schwendt wrote: FC-6]$ make build /usr/bin/plague-client build SDL_image SDL_image-1_2_5-2_fc6 fc6 Package SDL_image enqueued. Job ID: 22289. http://buildsys.fedoraproject.org/build-status/job.psp?uid=22289 22289: SDL_image-1.2.5-2.fc7 (building) Where does the .fc7 come from? This is the FC-6 branch! ill look at it tonight, im just about to walk out the door. Dennis Michael, Ive looked at this and it has to be something at your end not updated. i checked out SDL_image and did a make build and everything is correct http://buildsys.fedoraproject.org/build-status/job.psp?uid=22395 22395: SDL_image-1.2.5-3.fc6 (building) -- Dennis Gilmore, RHCE Proud Australian -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Initial EPEL mock config
Once upon a time Friday 10 November 2006 8:40 am, Josh Boyer wrote: On Thu, 2006-11-09 at 23:28 -0600, Dennis Gilmore wrote: [local] name=local baseurl=http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/ thats the correct url missing the fedora- So what exactly would be the full URL then? I'm slightly confused. that is the coreect url you had http://buildsys.fedoraproject.org/plague-results/4-epel/ Dennis pgp2sAEMz8g9l.pgp Description: PGP signature -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Initial EPEL mock config
On Thursday 09 November 2006 22:34, Josh Boyer wrote: Hi All, Below is an initial EPEL config. I'm not quite sure where packages will go, and I'm not sure if the CentOS base and updates are correct but I thought I would get this discussion started since EPEL is starting to move. Please review and let me know your thoughts. Again, this is just an example for now. thx, josh #!/usr/bin/python -tt import os config_opts['root'] = 'epel-4-i386' config_opts['target_arch'] = 'i386' config_opts['yum.conf'] = [main] cachdir=/var/cache/yum debuglevel=1 logfile=/var/log/yum.log reposdir=/dev/null retries=20 obsoletes=1 gpgcheck=0 assumeyes=1 # repos CentOS ones look good except we should hardcode the arch and version we are not going to have that info on the local system. [core] name=base mirrorlist=http://mirrorlist.centos.org/?release=4arch=i386repo=os [update] name=updates mirrorlist=http://mirrorlist.centos.org/?release=4arch=i386repo=updates [groups] name=groups baseurl=http://buildsys.fedoraproject.org/buildgroups/rhel4/i386/ [extras] name=epel mirrorlist=http://fedora.redhat.com/download/mirrors/epel-4 we should have it added to the mirror system so that users will get current local mirrors [local] name=local baseurl=http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/ thats the correct url missing the fedora- -- ,-._|\ Dennis Gilmore, RHCE / \ Proud Australian \_.--._/ | Aurora | Fedora | v -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: sparc weirdness
On Friday 18 August 2006 14:05, Jesse Keating wrote: On Friday 18 August 2006 14:48, Clark Williams wrote: If I'm correct here, the problem is that you need both 32-bit and 64-bit glibc's in the same chroot to build gcc for a sparc. I looked on a x86_64 FC5 system and it has two glibc-2.4-8 packages, but if you list them both, one is the 64 bit version and the other is the 32-bit version. This implies to me that they were both installed as opposed to updated. I can't really see an easy way to force mock/yum to do this, so I think the only way will be multiple invocations of mock and rpm. Something like: We handle this at Red Hat by having a file buildrequirement on a file that is provided by the 32bit glibc, as well as a buildrequirement on just glibc. This way no matter what arch you're on, you'll get the 32bit glibc. Now, at Red Hat we had to create a fake 'glibc32' package that is built x86_64 so that it is available in the x86_64 repo. Perhaps you can do the same for sparc? perhaps, but it needs to be the other way around. that is i need the 64 bit glibc in a 32bit chroot to build gcc. so i guess i need to build a glibc64 'fake' package gcc has a BuildRequires /lib64/libc.so.6 /usr/lib64/libc.so so its file based I will work out what i need to do for the glibc64 package Dennis -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
