From bugs.michael at gmx.net Sun Feb 3 23:50:33 2008 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 4 Feb 2008 00:50:33 +0100 Subject: Killing build jobs - mock python processes survive In-Reply-To: <47A22FDB.6000603@redhat.com> References: <20080131194018.6776e8d8.bugs.michael@gmx.net> <47A22FDB.6000603@redhat.com> Message-ID: <20080204005033.da23d3e5.bugs.michael@gmx.net> On Thu, 31 Jan 2008 15:30:19 -0500, Mike McLean 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 Hmmm... but is it successful? It finds more child process groups and kills them, but here it doesn't kill all of mock's processes either. To take a closer look I've ported the code into Plague (on F8). Below is one snapshot of the /proc stats of the build processes. The code finds process groups 16216 and 16220. After sending SIGTERM (or SIGKILL, doesn't matter) to pgrp -16216, pid 16216 is reported as killed, but pid 16219 is still running. Another waitpid on the pgrp gives "[Errno 10] No child processes". [16216, '(mock)', 'S', 16068, 16216, 2532, 34816, 16068, 4194560, 289, 0, 0, 0, 0, 0, 0, 0, 20, 0, 1, 0, 603929, 1642496, 48, 4294967295L, 134512640, 134516316, 3216708864L, 3216708516L, 1115138, 0, 0, 553652224, 0, 3225615909L, 0, 0, 17, 0, 0, 0, 0] [16219, '(python)', 'S', 16216, 16216, 2532, 34816, 16068, 4202752, 2067, 0, 0, 0, 41, 6, 0, 0, 20, 0, 1, 0, 603934, 13672448, 1764, 4294967295L, 134512640, 134514536, 3214952352L, 3214940384L, 1115138, 0, 0, 553652224, 8194, 0, 0, 0, 17, 0, 0, 0, 1] [16220, '(python)', 'S', 16219, 16220, 2532, 34816, 16068, 4202560, 343, 0, 0, 0, 0, 0, 0, 0, 20, 0, 1, 0, 603993, 13676544, 1109, 4294967295L, 134512640, 134514536, 3214952352L, 3214940384L, 1115138, 0, 0, 553652224, 2, 0, 0, 0, 17, 0, 0, 0, 0] [16221, '(tar)', 'S', 16220, 16220, 2532, 34816, 16068, 4194560, 891, 0, 0, 0, 80, 546, 0, 0, 20, 0, 1, 0, 603993, 2551808, 281, 4294967295L, 134508544, 134772428, 3217980208L, 3217979524L, 1115138, 0, 0, 553652224, 0, 0, 0, 0, 17, 0, 0, 0, 739] [16222, '(gzip)', 'D', 16221, 16220, 2532, 34816, 16068, 4194304, 167, 0, 0, 0, 650, 174, 0, 0, 20, 0, 1, 0, 603996, 2162688, 117, 4294967295L, 134508544, 134566708, 3220637264L, 3220635252L, 1115138, 0, 0, 553652224, 8404995, 0, 0, 0, 17, 0, 0, 0, 25] From bugs.michael at gmx.net Sun Feb 3 23:58:06 2008 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 4 Feb 2008 00:58:06 +0100 Subject: Killing build jobs - mock python processes survive In-Reply-To: <20080204005033.da23d3e5.bugs.michael@gmx.net> References: <20080131194018.6776e8d8.bugs.michael@gmx.net> <47A22FDB.6000603@redhat.com> <20080204005033.da23d3e5.bugs.michael@gmx.net> Message-ID: <20080204005806.9899a8da.bugs.michael@gmx.net> On Mon, 4 Feb 2008 00:50:33 +0100, Michael Schwendt wrote: > On Thu, 31 Jan 2008 15:30:19 -0500, Mike McLean 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 > > Hmmm... but is it successful? > > It finds more child process groups and kills them, but here it doesn't > kill all of mock's processes either. > > To take a closer look I've ported the code into Plague (on F8). Below is > one snapshot of the /proc stats of the build processes. The code finds > process groups 16216 and 16220. After sending SIGTERM (or SIGKILL, doesn't > matter) to pgrp -16216, pid 16216 is reported as killed, but pid 16219 is > still running. Another waitpid on the pgrp gives "[Errno 10] No child > processes". And the reason is that process 16219 gets a new parent as soon as its parent mock process 16216 is killed. When starting the builder from within the shell, that can be seen easily. From gary at mlbassoc.com Mon Feb 4 15:09:34 2008 From: gary at mlbassoc.com (Gary Thomas) Date: Mon, 04 Feb 2008 08:09:34 -0700 Subject: Troubles running pungi Message-ID: <47A72AAE.20500@mlbassoc.com> I'm having trouble running pungi. What's really troubling is that this exact recipe (set of commands) worked fine last Friday :-( The only thing that took place in the meantime was a power failure (this build system was idle at the time). I'm using the distributed kickstart file with the repo lines changed to be: # Add the repos you wish to use to compose here. At least one of them needs group data. repo --name=testing --baseurl=file:/mnt/work/fedora/AM Any ideas? [root at mac_mini pungi_f8]# time pungi -c f8-fedora.ks --all-stages --nosource Pungi.Gather:INFO: Adding repo testing Pungi.Gather:INFO: URL for repo testing is ['file:/mnt/work/fedora/AM'] Pungi.Gather:INFO: Getting sacks for arches ['ppc64', 'ppc', 'noarch', 'src'] Traceback (most recent call last): File "/usr/bin/pungi", line 178, in main() File "/usr/bin/pungi", line 66, in main mygather.getPackageObjects() File "/usr/lib/python2.5/site-packages/pypungi/gather.py", line 245, in getPackageObjects searchlist.extend(self.getPackagesFromGroup(group)) File "/usr/lib/python2.5/site-packages/pypungi/gather.py", line 191, in getPackagesFromGroup if not self.ayum.comps.has_group(group.name): File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 542, in comps = property(fget=lambda self: self._getGroups(), File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 505, in _getGroups groupfile = repo.getGroups() File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 884, in getGroups file = self.retrieveMD('group') File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 855, in retrieveMD cache=self.http_caching == 'all') File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 623, in _getFile raise Errors.NoMoreMirrorsRepoError, errstr yum.Errors.NoMoreMirrorsRepoError: failure: repodata/Fedora-8-comps.xml from testing: [Errno 256] No more mirrors to try. real 0m4.100s user 0m3.689s sys 0m0.388s [root at mac_mini pungi_f8]# sestatus SELinux status: disabled [root at mac_mini pungi_f8]# ls -l /mnt/work/fedora/AM/repodata/Fedora-8-comps.xml -rw-r--r-- 1 root root 1206345 2008-02-01 09:02 /mnt/work/fedora/AM/repodata/Fedora-8-comps.xml [root at mac_mini pungi_f8]# rpm -qi pungi Name : pungi Relocations: (not relocatable) Version : 1.1.9 Vendor: Fedora Project Release : 1.fc8 Build Date: Mon 29 Oct 2007 03:51:26 PM MDT Install Date: Fri 30 Nov 2007 05:40:33 AM MST Build Host: ppc3.fedora.redhat.com Group : Development/Tools Source RPM: pungi-1.1.9-1.fc8.src.rpm Size : 131116 License: GPLv2 Signature : DSA/SHA1, Mon 29 Oct 2007 08:20:47 PM MDT, Key ID b44269d04f2a6fd2 Packager : Fedora Project URL : http://hosted.fedoraproject.org/projects/pungi Summary : Distribution compose tool Description : A tool to create anaconda based installation trees/isos of a set of rpms. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ From gary at mlbassoc.com Tue Feb 5 19:58:38 2008 From: gary at mlbassoc.com (Gary Thomas) Date: Tue, 05 Feb 2008 12:58:38 -0700 Subject: Troubles running pungi In-Reply-To: <47A72AAE.20500@mlbassoc.com> References: <47A72AAE.20500@mlbassoc.com> Message-ID: <47A8BFEE.5060508@mlbassoc.com> Gary Thomas wrote: > I'm having trouble running pungi. What's really troubling is that this > exact recipe (set of commands) worked fine last Friday :-( The only > thing that took place in the meantime was a power failure (this build > system was idle at the time). > > I'm using the distributed kickstart file with the repo lines changed to > be: > # Add the repos you wish to use to compose here. At least one of them > needs group data. > repo --name=testing --baseurl=file:/mnt/work/fedora/AM > > Any ideas? > > [root at mac_mini pungi_f8]# time pungi -c f8-fedora.ks --all-stages > --nosource > Pungi.Gather:INFO: Adding repo testing > Pungi.Gather:INFO: URL for repo testing is ['file:/mnt/work/fedora/AM'] > Pungi.Gather:INFO: Getting sacks for arches ['ppc64', 'ppc', 'noarch', > 'src'] > Traceback (most recent call last): > File "/usr/bin/pungi", line 178, in > main() > File "/usr/bin/pungi", line 66, in main > mygather.getPackageObjects() > File "/usr/lib/python2.5/site-packages/pypungi/gather.py", line 245, > in getPackageObjects > searchlist.extend(self.getPackagesFromGroup(group)) > File "/usr/lib/python2.5/site-packages/pypungi/gather.py", line 191, > in getPackagesFromGroup > if not self.ayum.comps.has_group(group.name): > File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 542, in > > comps = property(fget=lambda self: self._getGroups(), > File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 505, in > _getGroups > groupfile = repo.getGroups() > File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 884, in > getGroups > file = self.retrieveMD('group') > File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 855, in > retrieveMD > cache=self.http_caching == 'all') > File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 623, in > _getFile > raise Errors.NoMoreMirrorsRepoError, errstr > yum.Errors.NoMoreMirrorsRepoError: failure: repodata/Fedora-8-comps.xml > from testing: [Errno 256] No more mirrors to try. > > real 0m4.100s > user 0m3.689s > sys 0m0.388s > > [root at mac_mini pungi_f8]# sestatus > SELinux status: disabled > > [root at mac_mini pungi_f8]# ls -l > /mnt/work/fedora/AM/repodata/Fedora-8-comps.xml > -rw-r--r-- 1 root root 1206345 2008-02-01 09:02 > /mnt/work/fedora/AM/repodata/Fedora-8-comps.xml > > [root at mac_mini pungi_f8]# rpm -qi pungi > Name : pungi Relocations: (not relocatable) > Version : 1.1.9 Vendor: Fedora Project > Release : 1.fc8 Build Date: Mon 29 Oct 2007 > 03:51:26 PM MDT > Install Date: Fri 30 Nov 2007 05:40:33 AM MST Build Host: > ppc3.fedora.redhat.com > Group : Development/Tools Source RPM: > pungi-1.1.9-1.fc8.src.rpm > Size : 131116 License: GPLv2 > Signature : DSA/SHA1, Mon 29 Oct 2007 08:20:47 PM MDT, Key ID > b44269d04f2a6fd2 > Packager : Fedora Project > URL : http://hosted.fedoraproject.org/projects/pungi > Summary : Distribution compose tool > Description : > A tool to create anaconda based installation trees/isos of a set of rpms. > I've figured out what happened. I *did* change something else which I forgot about. I edited the comps file for the repository to not include selinux-policy in @base. That's all. I just verified this by starting with the comps file from the original F8 repository. pungi worked as planned. Then I edited the comps file: [root at mac_mini pungi_test]# diff -u /work3/FC/fedora/releases/8/Everything/ppc/os/repodata/Fedora-8-comps.xml ../AM/repodata/ --- /work3/FC/fedora/releases/8/Everything/ppc/os/repodata/Fedora-8-comps.xml 2007-11-02 08:11:44.000000000 -0600 +++ ../AM/repodata/Fedora-8-comps.xml 2008-02-05 12:51:37.000000000 -0700 @@ -2217,7 +2217,6 @@ rootfiles rpm rsyslog - selinux-policy-targeted setserial setup shadow-utils This produced the crash/failure as documented above. Why? If this isn't to be allowed, at least a reasonable message instead of a traceback would be preferable. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ From jkeating at redhat.com Tue Feb 5 20:13:23 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Feb 2008 15:13:23 -0500 Subject: Troubles running pungi In-Reply-To: <47A8BFEE.5060508@mlbassoc.com> References: <47A72AAE.20500@mlbassoc.com> <47A8BFEE.5060508@mlbassoc.com> Message-ID: <20080205151323.6295c695@redhat.com> On Tue, 05 Feb 2008 12:58:38 -0700 Gary Thomas wrote: > This produced the crash/failure as documented above. Why? If this > isn't to be allowed, at least a reasonable message instead of a > traceback would be preferable. I won't disagree that I should have some error checking around the yum stuff, but the files in a yum repository are checksummed. If you edit the file, you have to re-run createrepo against that file to update the repodata. You've created corrupt repodata, and yum is rightfully balking on it. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gary at mlbassoc.com Tue Feb 5 21:17:10 2008 From: gary at mlbassoc.com (Gary Thomas) Date: Tue, 05 Feb 2008 14:17:10 -0700 Subject: Troubles running pungi In-Reply-To: <20080205151323.6295c695@redhat.com> References: <47A72AAE.20500@mlbassoc.com> <47A8BFEE.5060508@mlbassoc.com> <20080205151323.6295c695@redhat.com> Message-ID: <47A8D256.3050109@mlbassoc.com> Jesse Keating wrote: > On Tue, 05 Feb 2008 12:58:38 -0700 > Gary Thomas wrote: > >> This produced the crash/failure as documented above. Why? If this >> isn't to be allowed, at least a reasonable message instead of a >> traceback would be preferable. > > > I won't disagree that I should have some error checking around the yum > stuff, but the files in a yum repository are checksummed. If you edit > the file, you have to re-run createrepo against that file to update the > repodata. You've created corrupt repodata, and yum is rightfully > balking on it. Fair enough. That's not obvious since pungi is going to run createrepo itself, but I presume that's just against the selected packets. In any case, I now understand enough to move forward. Thanks -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ From bryce at zeniv.linux.org.uk Wed Feb 6 23:02:46 2008 From: bryce at zeniv.linux.org.uk (Bryce) Date: Wed, 06 Feb 2008 23:02:46 +0000 Subject: Dazed and confused.... Message-ID: <47AA3C96.3050707@zeniv.linux.org.uk> Just playing around with a miniature version of koji at home, building off my own box (i386/x86_64) using koji-1.2.5 Issue 1. The kernel, because my build host is defined as arch i386, x86_64 when I pass a kernel build in, it passes "--target i386" which leads to the usual train wreck of no i386 config how do I pass in i686 specifically for the kernel? Issue 2. One of the fun items in xen is that when you're building the 64bit version there is an odd dependency on pulling in a 32bit glibc-devel by adding /usr/include/gnu/stubs-32.h to the dependency list, when building in x86_64 that dependancy cannot get satisfied. How can I beat the tag into realizing it can pull from the i386 repo to fulfill that requirement? Phil =--= From mikeb at redhat.com Wed Feb 6 23:18:33 2008 From: mikeb at redhat.com (Mike Bonnet) Date: Wed, 06 Feb 2008 18:18:33 -0500 Subject: Dazed and confused.... In-Reply-To: <47AA3C96.3050707@zeniv.linux.org.uk> References: <47AA3C96.3050707@zeniv.linux.org.uk> Message-ID: <1202339913.1369.7.camel@localhost.localdomain> On Wed, 2008-02-06 at 23:02 +0000, Bryce wrote: > Just playing around with a miniature version of koji at home, building > off my own box (i386/x86_64) using koji-1.2.5 > > Issue 1. The kernel, because my build host is defined as arch i386, > x86_64 when I pass a kernel build in, it passes "--target i386" which > leads to the usual train wreck of no i386 config > how do I pass in i686 specifically for the kernel? You need to set the "extra arches" that a package gets built for, in addition to the arches defined for that tag. Use: koji set-pkg-arches "i686" dist-foo-build kernel In Fedora Koji the i386 build builds a kernel-headers package. If that's not working for you, you can avoid the i386 build altogether by putting "ExcludeArch: i386" into the spec file. > Issue 2. One of the fun items in xen is that when you're building the > 64bit version there is an odd dependency on pulling in a 32bit > glibc-devel by adding /usr/include/gnu/stubs-32.h to the dependency > list, when building in x86_64 that dependancy cannot get satisfied. How > can I beat the tag into realizing it can pull from the i386 repo to > fulfill that requirement? Fedora uses the glibc32 and glibc64 packages to provide these dependencies. A bit of a hack, but it works: http://cvs.fedoraproject.org/viewcvs/rpms/glibc32/devel/ http://cvs.fedoraproject.org/viewcvs/rpms/glibc64/devel/ Koji won't let you pull i386 packages into a x86_64 build environment, or vice versa. The build environments are single-arch only. From mikem at redhat.com Wed Feb 6 23:53:52 2008 From: mikem at redhat.com (Mike McLean) Date: Wed, 06 Feb 2008 18:53:52 -0500 Subject: Dazed and confused.... In-Reply-To: <47AA3C96.3050707@zeniv.linux.org.uk> References: <47AA3C96.3050707@zeniv.linux.org.uk> Message-ID: <47AA4890.3030609@redhat.com> Bryce wrote: > Issue 1. The kernel, because my build host is defined as arch i386, > x86_64 when I pass a kernel build in, it passes "--target i386" which > leads to the usual train wreck of no i386 config > how do I pass in i686 specifically for the kernel? The arches of your host are not directly passed to mock as you suggest. The build task will trigger builds for the arches in the archlist for the tag that the buildroot is based on (the build tag of the target). This list is modified in various ways. First any extra arches for package are added. You can control extra arches on a per-tag basis with the 'koji set-pkg-arches' command. This is probably the solution you are looking for. Secondly, the buildarchs, exclusivearch, and excludearch macros of the srpm are factored in. Note that the buildarchs macro is allowed to override the archlist, including expanding it. Thirdly, for scratch builds, the --arch-override option to the build command can override the arch list. For each arch in the resulting list, a buildArch subtask is created. This is where the arch list of a host comes into play. Note that the arch of the task is the canonicalized, so an i686 build is an i386 task. Hence your host with an archlist of 'i386 x86_64' will accept an i686 buildArch task. > Issue 2. One of the fun items in xen is that when you're building the > 64bit version there is an odd dependency on pulling in a 32bit > glibc-devel by adding /usr/include/gnu/stubs-32.h to the dependency > list, when building in x86_64 that dependancy cannot get satisfied. How > can I beat the tag into realizing it can pull from the i386 repo to > fulfill that requirement? Koji does not support multilib buildroots. Doing so /sanely/ is not nearly as simple as some would suggest. The way this is currently handled is to include a 64bit rpm that contains this needed 32bit content. This package may need to be added to the base install so that packages do not need to explicity require it. $ koji latest-pkg --quiet dist-f9-build glibc32 glibc32-2.4.90-13 dist-fc6-build jkeating From gary at mlbassoc.com Thu Feb 7 15:36:23 2008 From: gary at mlbassoc.com (Gary Thomas) Date: Thu, 07 Feb 2008 08:36:23 -0700 Subject: Local packages Message-ID: <47AB2577.8080206@mlbassoc.com> I'm trying to build a localized repository: Fedora + Updates + Local Packages Some of the local packages are derived from the mainline. I make some [minor] changes to match my hardware (sadly, my mods aren't suitable for pushing upstream). I want to keep the version+revision pretty much intact so I know where the package came from, etc. For example, I need to have a slightly modified X server (uncommon hardware, yeah!). So, I started with the package: xorg-x11-server-1.3.0.0-40.fc8.src.rpm I make my little change and rebuild, creating: xorg-x11-server-1.3.0.0-40_AM.fc8.src.rpm along with the desired binary packages. I'm trying to run pungi to create a munged/tailored repository, using the official versions of Fedora & Updates. Sadly, it seems that the original package always seems to override the one with my modifications, e.g. xorg-x11-server-1.3.0.0-40.fc8.src.rpm is chosen, even when both it and xorg-x11-server-1.3.0.0-40_AM.fc8.src.rpm are present. Is there a way to set the version so that my package always wins? That way, I can use the 100% official repositories as the starting point and only have my little mods. Thanks for any pointers n.b. at the moment, I'm just pruning the packages I need to change out of the official versions (local copies of course), but this is tedious and fraught with error. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ From jkeating at redhat.com Thu Feb 7 16:12:49 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Feb 2008 11:12:49 -0500 Subject: Local packages In-Reply-To: <47AB2577.8080206@mlbassoc.com> References: <47AB2577.8080206@mlbassoc.com> Message-ID: <20080207111249.2daffe02@redhat.com> On Thu, 07 Feb 2008 08:36:23 -0700 Gary Thomas wrote: > I'm trying to run pungi to create a munged/tailored repository, > using the official versions of Fedora & Updates. Sadly, it > seems that the original package always seems to override the > one with my modifications, e.g. > xorg-x11-server-1.3.0.0-40.fc8.src.rpm > is chosen, even when both it and > xorg-x11-server-1.3.0.0-40_AM.fc8.src.rpm > are present. > > Is there a way to set the version so that my package always > wins? That way, I can use the 100% official repositories as > the starting point and only have my little mods. When you modify the package, just add a .1 after the %{?dist} declaration. In your case, if you use rpmdev-vercomp you'll see that contrary to what you'd think, xorg-x11-server-1.3.0.0-40.fc8 is actually rpm newer than xorg-x11-server-1.3.0.0-40_AM.fc8: $ rpmdev-vercmp 0:1.3.0.0-40.fc8 0:1.3.0.0-40_AM.fc8 0:1.3.0.0-40.fc8 is newer But with a simple '.1' at the end of %{?dist} you get a newer package: [jkeating at lumos scripts]$ rpmdev-vercmp 0:1.3.0.0-40.fc8 0:1.3.0.0-40.fc8.1 0:1.3.0.0-40.fc8.1 is newer -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gary at mlbassoc.com Thu Feb 7 16:25:05 2008 From: gary at mlbassoc.com (Gary Thomas) Date: Thu, 07 Feb 2008 09:25:05 -0700 Subject: Local packages In-Reply-To: <20080207111249.2daffe02@redhat.com> References: <47AB2577.8080206@mlbassoc.com> <20080207111249.2daffe02@redhat.com> Message-ID: <47AB30E1.6070901@mlbassoc.com> Jesse Keating wrote: > On Thu, 07 Feb 2008 08:36:23 -0700 > Gary Thomas wrote: > >> I'm trying to run pungi to create a munged/tailored repository, >> using the official versions of Fedora & Updates. Sadly, it >> seems that the original package always seems to override the >> one with my modifications, e.g. >> xorg-x11-server-1.3.0.0-40.fc8.src.rpm >> is chosen, even when both it and >> xorg-x11-server-1.3.0.0-40_AM.fc8.src.rpm >> are present. >> >> Is there a way to set the version so that my package always >> wins? That way, I can use the 100% official repositories as >> the starting point and only have my little mods. > > When you modify the package, just add a .1 after the %{?dist} > declaration. > > In your case, if you use rpmdev-vercomp you'll see that contrary to > what you'd think, xorg-x11-server-1.3.0.0-40.fc8 is actually rpm newer > than xorg-x11-server-1.3.0.0-40_AM.fc8: > > $ rpmdev-vercmp 0:1.3.0.0-40.fc8 0:1.3.0.0-40_AM.fc8 > 0:1.3.0.0-40.fc8 is newer > > But with a simple '.1' at the end of %{?dist} you get a newer package: > > [jkeating at lumos scripts]$ rpmdev-vercmp 0:1.3.0.0-40.fc8 0:1.3.0.0-40.fc8.1 > 0:1.3.0.0-40.fc8.1 is newer Cool, thanks! 'rpmdev-vercmp' seems to be a very nice tool to know about. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ From f.bertoldi at gmail.com Fri Feb 8 08:02:35 2008 From: f.bertoldi at gmail.com (Fabio Fabio) Date: Fri, 8 Feb 2008 09:02:35 +0100 Subject: scanning logical volumes from initrd nash script Message-ID: Hi... The initrd nash script 'init' actually scans for logical volumes as follows: ..... code snippet from 'init' script ............ echo Scanning logical volumes lvm vgscan --ignorelockingfailure echo Activating logical volumes lvm vgchange -ay --ignorelockingfailure ** ....... end of code snippet ..... The volgroup name is fixed, it is written in the script itself. How to change this script in order to activate the logical volume name output of the 'vgscan' command? Nash is not the same as bash and I don't know how to do something like this: ------------------------------------------------------------------------ volgroup_name=`lvm vgscan --ignorelockingfailure` lvm vgchange -ay --ignorelockingfailure $volgroup_name ------------------------------------------------------------------------ Have you some suggestion ? .... Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From nando at ccrma.Stanford.EDU Sat Feb 9 01:00:30 2008 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Fri, 08 Feb 2008 17:00:30 -0800 Subject: [OT?] removing plague jobs... Message-ID: <1202518830.23093.58.camel@cmn3.stanford.edu> Would this be the right list for this question? I have a mock/plague build system I'm just configuring and I wonder how can I get rid of old builds? (ie: erase all related files and clean up the database). Should be simple[*], I must be missing something obvious... Thanks for any help... -- Fernando [*] something like "plague-remove " From bugs.michael at gmx.net Sat Feb 9 10:08:18 2008 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 9 Feb 2008 11:08:18 +0100 Subject: [OT?] removing plague jobs... In-Reply-To: <1202518830.23093.58.camel@cmn3.stanford.edu> References: <1202518830.23093.58.camel@cmn3.stanford.edu> Message-ID: <20080209110818.b10d15f0.bugs.michael@gmx.net> On Fri, 08 Feb 2008 17:00:30 -0800, Fernando Lopez-Lezcano wrote: > Would this be the right list for this question? > > I have a mock/plague build system I'm just configuring and I wonder how > can I get rid of old builds? (ie: erase all related files and clean up > the database). Should be simple[*], I must be missing something obvious... > > Thanks for any help... > -- Fernando > > [*] something like "plague-remove " It's not implemented. I think any stuff surrounding "what to do with successful builds in needsign?" is undefined and missing. There's "plague finish ", but it only marks a job as "finished", which does not trigger anything else than that finished jobs are not displayed in the www ui. Because a huge jobs database slows down Plague significantly (e.g. remote users see RPC timeouts for simple job status queries and would need to work around that with more complex queries), I've run the attached script periodically. Later, so none of the EPEL signers need to still run that, I've merged the following code into the buildsys: http://mschwendt.fedorapeople.org/plague-0.4.4.1-pushscript-extras.patch It deletes failed or finished jobs after two weeks and also marks anything, which is gone from plague-results directory, as finished. Maybe it's something you can use, too. -------------- next part -------------- A non-text attachment was scrubbed... Name: plague-clean.py Type: application/octet-stream Size: 1018 bytes Desc: not available URL: From nando at ccrma.Stanford.EDU Mon Feb 11 18:55:24 2008 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Mon, 11 Feb 2008 10:55:24 -0800 Subject: [OT?] removing plague jobs... In-Reply-To: <20080209110818.b10d15f0.bugs.michael@gmx.net> References: <1202518830.23093.58.camel@cmn3.stanford.edu> <20080209110818.b10d15f0.bugs.michael@gmx.net> Message-ID: <1202756124.7804.7.camel@cmn3.stanford.edu> On Sat, 2008-02-09 at 11:08 +0100, Michael Schwendt wrote: > On Fri, 08 Feb 2008 17:00:30 -0800, Fernando Lopez-Lezcano wrote: > > > Would this be the right list for this question? > > > > I have a mock/plague build system I'm just configuring and I wonder how > > can I get rid of old builds? (ie: erase all related files and clean up > > the database). Should be simple[*], I must be missing something obvious... > > > > Thanks for any help... > > > > [*] something like "plague-remove " > > It's not implemented. > > I think any stuff surrounding "what to do with successful builds in > needsign?" is undefined and missing. There's "plague finish ", but > it only marks a job as "finished", which does not trigger anything > else than that finished jobs are not displayed in the www ui. > > Because a huge jobs database slows down Plague significantly (e.g. remote > users see RPC timeouts for simple job status queries and would need to > work around that with more complex queries), I've run the attached script > periodically. Later, so none of the EPEL signers need to still run that, > I've merged the following code into the buildsys: > http://mschwendt.fedorapeople.org/plague-0.4.4.1-pushscript-extras.patch > It deletes failed or finished jobs after two weeks and also marks > anything, which is gone from plague-results directory, as finished. > > Maybe it's something you can use, too. Yes, thanks a lot, it will definitely help to keep the old builds from growing without bounds. -- Fernando From gary at mlbassoc.com Wed Feb 20 16:16:10 2008 From: gary at mlbassoc.com (Gary Thomas) Date: Wed, 20 Feb 2008 09:16:10 -0700 Subject: no kernel in pungi image Message-ID: <47BC524A.8040901@mlbassoc.com> Note: I'm not sure which list this belongs on - maybe anaconda-devel? I'm using pungi to build a distribution. If I build using anaconda-11.4.0.28, I get a good working build. If I use anaconda-11.4.0.36+ (from git 2008-02-19, just after 11.4.0.36), the result has no kernel package :-( I can see that it got scanned, but for some reason wasn't in the list of packages that yum installed. Can anyone give me a clue as to why? The logs from these builds, as well as the kickstart file, are at available from my website (too big for this list) http://www.mlbassoc.com/pungi-failures/AM_Fedora-min.ks http://www.mlbassoc.com/pungi-failures/ppc-anaconda-11.4.0.28.log http://www.mlbassoc.com/pungi-failures/ppc-anaconda-11.4.0.36.log Thanks -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ From doug.chapman at hp.com Thu Feb 21 22:10:16 2008 From: doug.chapman at hp.com (Doug Chapman) Date: Thu, 21 Feb 2008 17:10:16 -0500 Subject: odd build failures under koji/mock Message-ID: <1203631816.22443.53.camel@deimos.americas.hpqcorp.net> We have a koji server set up for ia64 where I have been running rawhide builds through. I am seeing something that I imagine is a regression in rpmbuild???? that is likely to be seen on the main koji server as well. Take for example this failed build of openser-1.3.0-8.fc9.src.rpm: On our ia64 koji server it failed with: + mv '/var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/openser/perl/*' /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/perl5/vendor_perl/5.8.8/ mv: cannot stat `/var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/openser/perl/*': No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.7626 (%install) The line in the specfile that triggered this is: mv $RPM_BUILD_ROOT/%{_libdir}/openser/perl/* somehow it appears it took the * path as literal. Looking at the main koji server at a build of the same package it expanded the * properly: + mv /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib64/openser/perl/OpenSER /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib64/openser/perl/OpenSER.pm /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/perl5/vendor_perl/5.8.8/ My only guess is this is a bug in rpmbuild which was introduced after openser was built on the main koji server (Feb 9th). I have several other packages failing in a similar manner, all fail to expand * properly. any ideas? The full build log of the failure can be seen at: http://ia64.koji.fedoraproject.org/koji/getfile?taskID=14457&name=build.log - Doug From jkeating at redhat.com Thu Feb 21 22:24:47 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 21 Feb 2008 17:24:47 -0500 Subject: odd build failures under koji/mock In-Reply-To: <1203631816.22443.53.camel@deimos.americas.hpqcorp.net> References: <1203631816.22443.53.camel@deimos.americas.hpqcorp.net> Message-ID: <20080221172447.17cd263c@redhat.com> On Thu, 21 Feb 2008 17:10:16 -0500 Doug Chapman wrote: > any ideas? If you're running RHEL5 on the builders, it sounds like the tux open flag bug that was recently fixed and released as errata. Please be sure you're running the latest offered RHEL5 kernel. 2.6.18-53.1.6.el5 or later is needed. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From orion at cora.nwra.com Thu Feb 21 22:30:26 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 21 Feb 2008 15:30:26 -0700 Subject: odd build failures under koji/mock In-Reply-To: <1203631816.22443.53.camel@deimos.americas.hpqcorp.net> References: <1203631816.22443.53.camel@deimos.americas.hpqcorp.net> Message-ID: <47BDFB82.2020105@cora.nwra.com> Doug Chapman wrote: > We have a koji server set up for ia64 where I have been running rawhide > builds through. I am seeing something that I imagine is a regression in > rpmbuild???? that is likely to be seen on the main koji server as well. > > Take for example this failed build of openser-1.3.0-8.fc9.src.rpm: > > On our ia64 koji server it failed with: > > + mv '/var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/openser/perl/*' /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/perl5/vendor_perl/5.8.8/ > mv: cannot stat `/var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/openser/perl/*': No such file or directory > error: Bad exit status from /var/tmp/rpm-tmp.7626 (%install) > > > The line in the specfile that triggered this is: > > mv $RPM_BUILD_ROOT/%{_libdir}/openser/perl/* > > > somehow it appears it took the * path as literal. > > Looking at the main koji server at a build of the same package it > expanded the * properly: > > + mv /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib64/openser/perl/OpenSER /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib64/openser/perl/OpenSER.pm /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/perl5/vendor_perl/5.8.8/ > > My only guess is this is a bug in rpmbuild which was introduced after > openser was built on the main koji server (Feb 9th). > > I have several other packages failing in a similar manner, all fail to > expand * properly. > > any ideas? > > The full build log of the failure can be seen at: > http://ia64.koji.fedoraproject.org/koji/getfile?taskID=14457&name=build.log I see /usr/lib64 referenced everywhere above, but then /usr/lib for the move? The files are in /usr/lib64/openser/perl/, that's why the * doesn't expand. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From doug.chapman at hp.com Thu Feb 21 22:50:53 2008 From: doug.chapman at hp.com (Doug Chapman) Date: Thu, 21 Feb 2008 17:50:53 -0500 Subject: odd build failures under koji/mock In-Reply-To: <47BDFB82.2020105@cora.nwra.com> References: <1203631816.22443.53.camel@deimos.americas.hpqcorp.net> <47BDFB82.2020105@cora.nwra.com> Message-ID: <1203634253.22443.58.camel@deimos.americas.hpqcorp.net> On Thu, 2008-02-21 at 15:30 -0700, Orion Poplawski wrote: > Doug Chapman wrote: > > We have a koji server set up for ia64 where I have been running rawhide > > builds through. I am seeing something that I imagine is a regression in > > rpmbuild???? that is likely to be seen on the main koji server as well. > > > > Take for example this failed build of openser-1.3.0-8.fc9.src.rpm: > > > > On our ia64 koji server it failed with: > > > > + mv '/var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/openser/perl/*' /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/perl5/vendor_perl/5.8.8/ > > mv: cannot stat `/var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/openser/perl/*': No such file or directory > > error: Bad exit status from /var/tmp/rpm-tmp.7626 (%install) > > > > > > The line in the specfile that triggered this is: > > > > mv $RPM_BUILD_ROOT/%{_libdir}/openser/perl/* > > > > > > somehow it appears it took the * path as literal. > > > > Looking at the main koji server at a build of the same package it > > expanded the * properly: > > > > + mv /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib64/openser/perl/OpenSER /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib64/openser/perl/OpenSER.pm /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/perl5/vendor_perl/5.8.8/ > > > > My only guess is this is a bug in rpmbuild which was introduced after > > openser was built on the main koji server (Feb 9th). > > > > I have several other packages failing in a similar manner, all fail to > > expand * properly. > > > > any ideas? > > > > The full build log of the failure can be seen at: > > http://ia64.koji.fedoraproject.org/koji/getfile?taskID=14457&name=build.log > > I see /usr/lib64 referenced everywhere above, but then /usr/lib for the > move? The files are in /usr/lib64/openser/perl/, that's why the * > doesn't expand. > Nice catch! Had not noticed that. I will look into a patch so the package does the right thing on ia64. - Doug From bugs.michael at gmx.net Fri Feb 22 10:17:29 2008 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 22 Feb 2008 11:17:29 +0100 Subject: odd build failures under koji/mock In-Reply-To: <1203631816.22443.53.camel@deimos.americas.hpqcorp.net> References: <1203631816.22443.53.camel@deimos.americas.hpqcorp.net> Message-ID: <20080222111729.5bdf8d19.bugs.michael@gmx.net> On Thu, 21 Feb 2008 17:10:16 -0500, Doug Chapman wrote: > We have a koji server set up for ia64 where I have been running rawhide > builds through. I am seeing something that I imagine is a regression in > rpmbuild???? that is likely to be seen on the main koji server as well. > > Take for example this failed build of openser-1.3.0-8.fc9.src.rpm: > > On our ia64 koji server it failed with: > > + mv '/var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/openser/perl/*' /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/perl5/vendor_perl/5.8.8/ > mv: cannot stat `/var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/openser/perl/*': No such file or directory > error: Bad exit status from /var/tmp/rpm-tmp.7626 (%install) Does the mv really use the single quotes like that? Then it's clear why the * doesn't expand. > somehow it appears it took the * path as literal. > > Looking at the main koji server at a build of the same package it > expanded the * properly: > > + mv /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib64/openser/perl/OpenSER /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib64/openser/perl/OpenSER.pm /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/perl5/vendor_perl/5.8.8/ > From jkeating at redhat.com Fri Feb 22 12:40:59 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Feb 2008 07:40:59 -0500 Subject: odd build failures under koji/mock In-Reply-To: <20080222111729.5bdf8d19.bugs.michael@gmx.net> References: <1203631816.22443.53.camel@deimos.americas.hpqcorp.net> <20080222111729.5bdf8d19.bugs.michael@gmx.net> Message-ID: <20080222074059.6d6c2ac2@redhat.com> On Fri, 22 Feb 2008 11:17:29 +0100 Michael Schwendt wrote: > > + mv > > '/var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/openser/perl/*' /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/perl5/vendor_perl/5.8.8/ > > mv: cannot stat > > `/var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/openser/perl/*': > > No such file or directory error: Bad exit status > > from /var/tmp/rpm-tmp.7626 (%install) > > Does the mv really use the single quotes like that? > Then it's clear why the * doesn't expand. Eh, that's just how bash spits things out if you run it with -x. If you look in the rpm script itself it doesn't have single quotes. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From bugs.michael at gmx.net Fri Feb 22 23:34:05 2008 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 23 Feb 2008 00:34:05 +0100 Subject: odd build failures under koji/mock In-Reply-To: <20080222074059.6d6c2ac2@redhat.com> References: <1203631816.22443.53.camel@deimos.americas.hpqcorp.net> <20080222111729.5bdf8d19.bugs.michael@gmx.net> <20080222074059.6d6c2ac2@redhat.com> Message-ID: <20080223003405.a096775d.bugs.michael@gmx.net> On Fri, 22 Feb 2008 07:40:59 -0500, Jesse Keating wrote: > On Fri, 22 Feb 2008 11:17:29 +0100 > Michael Schwendt wrote: > > > > + mv > > > '/var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/openser/perl/*' /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/perl5/vendor_perl/5.8.8/ > > > mv: cannot stat > > > `/var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/openser/perl/*': > > > No such file or directory error: Bad exit status > > > from /var/tmp/rpm-tmp.7626 (%install) > > > > Does the mv really use the single quotes like that? > > Then it's clear why the * doesn't expand. > > Eh, that's just how bash spits things out if you run it with -x. Are you sure? I cannot reproduce that with -x. Please demonstrate. A counter-example was quoted a bit below in the original mail: > + mv /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib64/openser/perl/OpenSER /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib64/openser/perl/OpenSER.pm /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/perl5/vendor_perl/5.8.8/ > From doug.chapman at hp.com Sat Feb 23 00:54:34 2008 From: doug.chapman at hp.com (Doug Chapman) Date: Fri, 22 Feb 2008 19:54:34 -0500 Subject: odd build failures under koji/mock In-Reply-To: <20080223003405.a096775d.bugs.michael@gmx.net> References: <1203631816.22443.53.camel@deimos.americas.hpqcorp.net> <20080222111729.5bdf8d19.bugs.michael@gmx.net> <20080222074059.6d6c2ac2@redhat.com> <20080223003405.a096775d.bugs.michael@gmx.net> Message-ID: <1203728074.6598.1.camel@athlon> On Sat, 2008-02-23 at 00:34 +0100, Michael Schwendt wrote: > On Fri, 22 Feb 2008 07:40:59 -0500, Jesse Keating wrote: > > > On Fri, 22 Feb 2008 11:17:29 +0100 > > Michael Schwendt wrote: > > > > > > + mv > > > > '/var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/openser/perl/*' /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/perl5/vendor_perl/5.8.8/ > > > > mv: cannot stat > > > > `/var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/openser/perl/*': > > > > No such file or directory error: Bad exit status > > > > from /var/tmp/rpm-tmp.7626 (%install) > > > > > > Does the mv really use the single quotes like that? > > > Then it's clear why the * doesn't expand. > > > > Eh, that's just how bash spits things out if you run it with -x. > > Are you sure? I cannot reproduce that with -x. Please demonstrate. $ sh -x foo.sh + cp 'missingfile/*' /tmp cp: cannot stat `missingfile/*': No such file or directory - Doug From jkeating at redhat.com Sat Feb 23 01:18:36 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Feb 2008 20:18:36 -0500 Subject: odd build failures under koji/mock In-Reply-To: <1203728074.6598.1.camel@athlon> References: <1203631816.22443.53.camel@deimos.americas.hpqcorp.net> <20080222111729.5bdf8d19.bugs.michael@gmx.net> <20080222074059.6d6c2ac2@redhat.com> <20080223003405.a096775d.bugs.michael@gmx.net> <1203728074.6598.1.camel@athlon> Message-ID: <20080222201836.01dbee0b@redhat.com> On Fri, 22 Feb 2008 19:54:34 -0500 Doug Chapman wrote: > $ sh -x foo.sh > + cp 'missingfile/*' /tmp > cp: cannot stat `missingfile/*': No such file or directory For completeness, please show 'foo.sh' (: -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From doug.chapman at hp.com Sat Feb 23 01:21:56 2008 From: doug.chapman at hp.com (Doug Chapman) Date: Fri, 22 Feb 2008 20:21:56 -0500 Subject: odd build failures under koji/mock In-Reply-To: <20080222201836.01dbee0b@redhat.com> References: <1203631816.22443.53.camel@deimos.americas.hpqcorp.net> <20080222111729.5bdf8d19.bugs.michael@gmx.net> <20080222074059.6d6c2ac2@redhat.com> <20080223003405.a096775d.bugs.michael@gmx.net> <1203728074.6598.1.camel@athlon> <20080222201836.01dbee0b@redhat.com> Message-ID: <1203729716.6598.4.camel@athlon> On Fri, 2008-02-22 at 20:18 -0500, Jesse Keating wrote: > On Fri, 22 Feb 2008 19:54:34 -0500 > Doug Chapman wrote: > > > $ sh -x foo.sh > > + cp 'missingfile/*' /tmp > > cp: cannot stat `missingfile/*': No such file or directory > > > For completeness, please show 'foo.sh' (: oh yeah, just like my 5rd grade teacher said, "show your work!" $ cat foo.sh #!/bin/sh cp missingfile/* /tmp The key here being that "missingfile" does not exist, which was the root of my original issue. - Doug From jkeating at redhat.com Sat Feb 23 01:31:34 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Feb 2008 20:31:34 -0500 Subject: odd build failures under koji/mock In-Reply-To: <1203729716.6598.4.camel@athlon> References: <1203631816.22443.53.camel@deimos.americas.hpqcorp.net> <20080222111729.5bdf8d19.bugs.michael@gmx.net> <20080222074059.6d6c2ac2@redhat.com> <20080223003405.a096775d.bugs.michael@gmx.net> <1203728074.6598.1.camel@athlon> <20080222201836.01dbee0b@redhat.com> <1203729716.6598.4.camel@athlon> Message-ID: <20080222203134.61829250@redhat.com> On Fri, 22 Feb 2008 20:21:56 -0500 Doug Chapman wrote: > The key here being that "missingfile" does not exist, which was the > root of my original issue. Nod, speaking of that original issue, is it still an issue or was the root cause found? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From doug.chapman at hp.com Sat Feb 23 01:48:37 2008 From: doug.chapman at hp.com (Doug Chapman) Date: Fri, 22 Feb 2008 20:48:37 -0500 Subject: odd build failures under koji/mock In-Reply-To: <20080222203134.61829250@redhat.com> References: <1203631816.22443.53.camel@deimos.americas.hpqcorp.net> <20080222111729.5bdf8d19.bugs.michael@gmx.net> <20080222074059.6d6c2ac2@redhat.com> <20080223003405.a096775d.bugs.michael@gmx.net> <1203728074.6598.1.camel@athlon> <20080222201836.01dbee0b@redhat.com> <1203729716.6598.4.camel@athlon> <20080222203134.61829250@redhat.com> Message-ID: <1203731317.6598.11.camel@athlon> On Fri, 2008-02-22 at 20:31 -0500, Jesse Keating wrote: > On Fri, 22 Feb 2008 20:21:56 -0500 > Doug Chapman wrote: > > > The key here being that "missingfile" does not exist, which was the > > root of my original issue. > > Nod, speaking of that original issue, is it still an issue or was the > root cause found? Interesting thing is there were 2 issues. I had several builds fail when the files _were_ there and I think your suggestion on updating the kernel on the builders fixed that issue (at least I cannot reproduce after the kernel update). Then there was the failure with openser which I assumed was the same sort of issue but as the others but as someone pointed out the install was putting the perl libs in /usr/lib64 instead of /usr/lib. A simple specfile fix for that has been found. - Doug From bugs.michael at gmx.net Sat Feb 23 10:19:17 2008 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 23 Feb 2008 11:19:17 +0100 Subject: odd build failures under koji/mock In-Reply-To: <1203729716.6598.4.camel@athlon> References: <1203631816.22443.53.camel@deimos.americas.hpqcorp.net> <20080222111729.5bdf8d19.bugs.michael@gmx.net> <20080222074059.6d6c2ac2@redhat.com> <20080223003405.a096775d.bugs.michael@gmx.net> <1203728074.6598.1.camel@athlon> <20080222201836.01dbee0b@redhat.com> <1203729716.6598.4.camel@athlon> Message-ID: <20080223111917.f91e7130.bugs.michael@gmx.net> On Fri, 22 Feb 2008 20:21:56 -0500, Doug Chapman wrote: > > On Fri, 2008-02-22 at 20:18 -0500, Jesse Keating wrote: > > On Fri, 22 Feb 2008 19:54:34 -0500 > > Doug Chapman wrote: > > > > > $ sh -x foo.sh > > > + cp 'missingfile/*' /tmp > > > cp: cannot stat `missingfile/*': No such file or directory > > > > > > For completeness, please show 'foo.sh' (: > > oh yeah, just like my 5rd grade teacher said, "show your work!" > > $ cat foo.sh > #!/bin/sh > cp missingfile/* /tmp > > > The key here being that "missingfile" does not exist, which was the root > of my original issue. thanks, that's the key to reproducing it with non-builtins. if it expands to existing paths, the quotes are not added in the xtrace. If, however, the quotes exist in the script, that can not be concluded from watching only the xtrace. From jkeating at redhat.com Sat Feb 23 12:30:34 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 23 Feb 2008 07:30:34 -0500 Subject: odd build failures under koji/mock In-Reply-To: <20080223111917.f91e7130.bugs.michael@gmx.net> References: <1203631816.22443.53.camel@deimos.americas.hpqcorp.net> <20080222111729.5bdf8d19.bugs.michael@gmx.net> <20080222074059.6d6c2ac2@redhat.com> <20080223003405.a096775d.bugs.michael@gmx.net> <1203728074.6598.1.camel@athlon> <20080222201836.01dbee0b@redhat.com> <1203729716.6598.4.camel@athlon> <20080223111917.f91e7130.bugs.michael@gmx.net> Message-ID: <20080223073034.56405bfb@redhat.com> On Sat, 23 Feb 2008 11:19:17 +0100 Michael Schwendt wrote: > thanks, that's the key to reproducing it with non-builtins. if it > expands to existing paths, the quotes are not added in the xtrace. > If, however, the quotes exist in the script, that can not be > concluded from watching only the xtrace. You are correct. I had made an assumption based on what I had just gone through with the kernel issue. I chased the wild goose of quoting for a bit until we realized that xtrace just gets it wrong when outputing when a file isn't found. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mikem at redhat.com Wed Feb 27 00:14:44 2008 From: mikem at redhat.com (Mike McLean) Date: Tue, 26 Feb 2008 19:14:44 -0500 Subject: rebuilding from old cvs tags Message-ID: <47C4AB74.5010202@redhat.com> 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. 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. 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? From dennis at ausil.us Wed Feb 27 00:33:12 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 26 Feb 2008 18:33:12 -0600 Subject: rebuilding from old cvs tags In-Reply-To: <47C4AB74.5010202@redhat.com> References: <47C4AB74.5010202@redhat.com> Message-ID: <200802261833.18417.dennis@ausil.us> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From Matt_Domsch at dell.com Wed Feb 27 22:15:49 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 27 Feb 2008 16:15:49 -0600 Subject: rebuilding from old cvs tags In-Reply-To: <200802261833.18417.dennis@ausil.us> References: <47C4AB74.5010202@redhat.com> <200802261833.18417.dennis@ausil.us> Message-ID: <20080227221548.GA10362@auslistsprd01.us.dell.com> On Tue, Feb 26, 2008 at 06:33:12PM -0600, Dennis Gilmore wrote: > 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. I started the 'correspondingsource' project on fedorahosted.org today exactly for such a webapp. We have just over 85k tags for all the packages in CVS; some going back to 2004, some only to the F7 days. Not sure yet how much history was lost during the Core import. We've talked about "immutable tags" before. While that would be nice, I'd be fine with having koji add a tag in its own namespace, either at package checkout pre-build, or on succcessful build, either way is fine by me. These tags would not be the same tags as 'make tag' creates, so users can force-tag if they really feel the need, but we would more than strongly discourage force tagging on the koji namespace tags. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From ivazqueznet at gmail.com Wed Feb 27 22:32:43 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Wed, 27 Feb 2008 17:32:43 -0500 Subject: rebuilding from old cvs tags In-Reply-To: <20080227221548.GA10362@auslistsprd01.us.dell.com> References: <47C4AB74.5010202@redhat.com> <200802261833.18417.dennis@ausil.us> <20080227221548.GA10362@auslistsprd01.us.dell.com> Message-ID: <1204151563.31076.1.camel@ignacio.lan> On Wed, 2008-02-27 at 16:15 -0600, Matt Domsch wrote: > We have just over 85k tags for all the packages in CVS; some going > back to 2004, some only to the F7 days. Not sure yet how much history > was lost during the Core import. Not much I don't think. It just wasn't all pulled in. http://cvs.fedoraproject.org/viewcvs/?root=core -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Matt_Domsch at dell.com Thu Feb 28 05:47:51 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 27 Feb 2008 23:47:51 -0600 Subject: rebuilding from old cvs tags In-Reply-To: <1204151563.31076.1.camel@ignacio.lan> References: <47C4AB74.5010202@redhat.com> <200802261833.18417.dennis@ausil.us> <20080227221548.GA10362@auslistsprd01.us.dell.com> <1204151563.31076.1.camel@ignacio.lan> Message-ID: <20080228054751.GA25382@auslistsprd01.us.dell.com> On Wed, Feb 27, 2008 at 05:32:43PM -0500, Ignacio Vazquez-Abrams wrote: > On Wed, 2008-02-27 at 16:15 -0600, Matt Domsch wrote: > > We have just over 85k tags for all the packages in CVS; some going > > back to 2004, some only to the F7 days. Not sure yet how much history > > was lost during the Core import. > > Not much I don't think. It just wasn't all pulled in. > > http://cvs.fedoraproject.org/viewcvs/?root=core Oh, excellent, I didn't know that was still around and online. That'll make it much easier to get those historical tags. Thanks for pointing that out. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mikeb at redhat.com Thu Feb 28 16:09:24 2008 From: mikeb at redhat.com (Mike Bonnet) Date: Thu, 28 Feb 2008 11:09:24 -0500 Subject: rebuilding from old cvs tags In-Reply-To: <20080227221548.GA10362@auslistsprd01.us.dell.com> References: <47C4AB74.5010202@redhat.com> <200802261833.18417.dennis@ausil.us> <20080227221548.GA10362@auslistsprd01.us.dell.com> Message-ID: <1204214965.26372.10.camel@burren.boston.redhat.com> On Wed, 2008-02-27 at 16:15 -0600, Matt Domsch wrote: > On Tue, Feb 26, 2008 at 06:33:12PM -0600, Dennis Gilmore wrote: > > 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. > > I started the 'correspondingsource' project on fedorahosted.org today > exactly for such a webapp. > > We have just over 85k tags for all the packages in CVS; some going > back to 2004, some only to the F7 days. Not sure yet how much history > was lost during the Core import. > > We've talked about "immutable tags" before. While that would be nice, > I'd be fine with having koji add a tag in its own namespace, either > at package checkout pre-build, or on succcessful build, either way is > fine by me. These tags would not be the same tags as 'make tag' > creates, so users can force-tag if they really feel the need, but we > would more than strongly discourage force tagging on the koji > namespace tags. I'm not really comfortable having an automated system (Koji) modifying the SCM. Giving the Koji builders credentials to modify the SCM in a secure way (without making those credentials available to the world) might be tricky. It also dramatically increases the risk in the event that a builder is compromised. Right now all Koji access to the SCM is read-only, and it should probably stay that way. I think immutable tags are the answer here. We already kind of assume tags don't change once they're built, we might as well enforce it. I know force-tag is convenient, but how much harder is it really to bump the revision number instead? From notting at redhat.com Thu Feb 28 16:12:05 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 28 Feb 2008 11:12:05 -0500 Subject: rebuilding from old cvs tags In-Reply-To: <1204214965.26372.10.camel@burren.boston.redhat.com> References: <47C4AB74.5010202@redhat.com> <200802261833.18417.dennis@ausil.us> <20080227221548.GA10362@auslistsprd01.us.dell.com> <1204214965.26372.10.camel@burren.boston.redhat.com> Message-ID: <20080228161205.GB11604@nostromo.devel.redhat.com> Mike Bonnet (mikeb at redhat.com) said: > I think immutable tags are the answer here. We already kind of assume > tags don't change once they're built, we might as well enforce it. I > know force-tag is convenient, but how much harder is it really to bump > the revision number instead? In the case of transient build errors, it's rather annoying. Bill From mikeb at redhat.com Thu Feb 28 16:17:37 2008 From: mikeb at redhat.com (Mike Bonnet) Date: Thu, 28 Feb 2008 11:17:37 -0500 Subject: rebuilding from old cvs tags In-Reply-To: <20080228161205.GB11604@nostromo.devel.redhat.com> References: <47C4AB74.5010202@redhat.com> <200802261833.18417.dennis@ausil.us> <20080227221548.GA10362@auslistsprd01.us.dell.com> <1204214965.26372.10.camel@burren.boston.redhat.com> <20080228161205.GB11604@nostromo.devel.redhat.com> Message-ID: <1204215457.26372.14.camel@burren.boston.redhat.com> On Thu, 2008-02-28 at 11:12 -0500, Bill Nottingham wrote: > Mike Bonnet (mikeb at redhat.com) said: > > I think immutable tags are the answer here. We already kind of assume > > tags don't change once they're built, we might as well enforce it. I > > know force-tag is convenient, but how much harder is it really to bump > > the revision number instead? > > In the case of transient build errors, it's rather annoying. If a transient build error (build system hiccup) prevented the build from completing, you should be able to rebuild from the same tag. Yes, I know there are some failure modes where this does not work, but we're working on addressing those, and they should be the minority of cases. From notting at redhat.com Thu Feb 28 16:58:43 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 28 Feb 2008 11:58:43 -0500 Subject: rebuilding from old cvs tags In-Reply-To: <1204215457.26372.14.camel@burren.boston.redhat.com> References: <47C4AB74.5010202@redhat.com> <200802261833.18417.dennis@ausil.us> <20080227221548.GA10362@auslistsprd01.us.dell.com> <1204214965.26372.10.camel@burren.boston.redhat.com> <20080228161205.GB11604@nostromo.devel.redhat.com> <1204215457.26372.14.camel@burren.boston.redhat.com> Message-ID: <20080228165843.GA16993@nostromo.devel.redhat.com> Mike Bonnet (mikeb at redhat.com) said: > If a transient build error (build system hiccup) prevented the build > from completing, you should be able to rebuild from the same tag. > > Yes, I know there are some failure modes where this does not work, but > we're working on addressing those, and they should be the minority of > cases. True, but if it's something like 'a build dependent package is broken', you're unlikely to remember to just re-push the task two days later when it's fixed. In any case, turning off force tag would lead to either: - needless release & changelog inflation or - usage of scratch builds just to test that it builds everywhere Actually, do we even know if disabling force tag can be worked around? Bill From mikeb at redhat.com Thu Feb 28 17:29:24 2008 From: mikeb at redhat.com (Mike Bonnet) Date: Thu, 28 Feb 2008 12:29:24 -0500 Subject: rebuilding from old cvs tags In-Reply-To: <20080228165843.GA16993@nostromo.devel.redhat.com> References: <47C4AB74.5010202@redhat.com> <200802261833.18417.dennis@ausil.us> <20080227221548.GA10362@auslistsprd01.us.dell.com> <1204214965.26372.10.camel@burren.boston.redhat.com> <20080228161205.GB11604@nostromo.devel.redhat.com> <1204215457.26372.14.camel@burren.boston.redhat.com> <20080228165843.GA16993@nostromo.devel.redhat.com> Message-ID: <1204219764.26372.23.camel@burren.boston.redhat.com> On Thu, 2008-02-28 at 11:58 -0500, Bill Nottingham wrote: > Mike Bonnet (mikeb at redhat.com) said: > > If a transient build error (build system hiccup) prevented the build > > from completing, you should be able to rebuild from the same tag. > > > > Yes, I know there are some failure modes where this does not work, but > > we're working on addressing those, and they should be the minority of > > cases. > > True, but if it's something like 'a build dependent package is broken', > you're unlikely to remember to just re-push the task two days later > when it's fixed. I don't see how disabling force-tagging has any effect on this. Remember you can rebuild with the same tag if the build fails. > In any case, turning off force tag would lead to > either: > > - needless release & changelog inflation Do we require people to add a changelog entry for *every* increment of the release number? If you're just bumping the release for a rebuild, it seems reasonable to not bother with the changelog entry. > or > > - usage of scratch builds just to test that it builds everywhere > If the build fails because of a problem with a dependent package, you can rebuild from the same tag once the dependent package is fixed. If the build fails because of a problem with the spec file or source, you need to change something to make it build successfully. Bumping the release and adding a changelog entry seems appropriate in this case. I'd argue that even *now* we should be discouraging force-tag in this case. > Actually, do we even know if disabling force tag can be worked around? Not sure what you're asking here. There's no reason force-tag is required for any part of the package maintenance workflow. From paul at city-fan.org Thu Feb 28 18:24:59 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 28 Feb 2008 18:24:59 +0000 Subject: rebuilding from old cvs tags In-Reply-To: <1204219764.26372.23.camel@burren.boston.redhat.com> References: <47C4AB74.5010202@redhat.com> <200802261833.18417.dennis@ausil.us> <20080227221548.GA10362@auslistsprd01.us.dell.com> <1204214965.26372.10.camel@burren.boston.redhat.com> <20080228161205.GB11604@nostromo.devel.redhat.com> <1204215457.26372.14.camel@burren.boston.redhat.com> <20080228165843.GA16993@nostromo.devel.redhat.com> <1204219764.26372.23.camel@burren.boston.redhat.com> Message-ID: <20080228182459.0ce9a0c1@metropolis.intra.city-fan.org> On Thu, 28 Feb 2008 12:29:24 -0500 Mike Bonnet wrote: > On Thu, 2008-02-28 at 11:58 -0500, Bill Nottingham wrote: > > Mike Bonnet (mikeb at redhat.com) said: > > > If a transient build error (build system hiccup) prevented the > > > build from completing, you should be able to rebuild from the > > > same tag. > > > > > > Yes, I know there are some failure modes where this does not > > > work, but we're working on addressing those, and they should be > > > the minority of cases. > > > > True, but if it's something like 'a build dependent package is > > broken', you're unlikely to remember to just re-push the task two > > days later when it's fixed. > > I don't see how disabling force-tagging has any effect on this. > Remember you can rebuild with the same tag if the build fails. > > > In any case, turning off force tag would lead to > > either: > > > > - needless release & changelog inflation > > Do we require people to add a changelog entry for *every* increment of > the release number? If you're just bumping the release for a rebuild, > it seems reasonable to not bother with the changelog entry. > > > or > > > > - usage of scratch builds just to test that it builds everywhere > > > > If the build fails because of a problem with a dependent package, you > can rebuild from the same tag once the dependent package is fixed. > > If the build fails because of a problem with the spec file or source, > you need to change something to make it build successfully. Bumping > the release and adding a changelog entry seems appropriate in this > case. I'd argue that even *now* we should be discouraging force-tag > in this case. > > > Actually, do we even know if disabling force tag can be worked > > around? > > Not sure what you're asking here. There's no reason force-tag is > required for any part of the package maintenance workflow. I've used it after I've done a "make tag" whilst forgetting to commit changes first, so the tag was applied to the wrong version of the spec file etc. Force tagging is useful for correcting this error. Paul. From jkeating at redhat.com Thu Feb 28 18:45:52 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Feb 2008 13:45:52 -0500 Subject: rebuilding from old cvs tags In-Reply-To: <20080228182459.0ce9a0c1@metropolis.intra.city-fan.org> References: <47C4AB74.5010202@redhat.com> <200802261833.18417.dennis@ausil.us> <20080227221548.GA10362@auslistsprd01.us.dell.com> <1204214965.26372.10.camel@burren.boston.redhat.com> <20080228161205.GB11604@nostromo.devel.redhat.com> <1204215457.26372.14.camel@burren.boston.redhat.com> <20080228165843.GA16993@nostromo.devel.redhat.com> <1204219764.26372.23.camel@burren.boston.redhat.com> <20080228182459.0ce9a0c1@metropolis.intra.city-fan.org> Message-ID: <20080228134552.0995092c@redhat.com> On Thu, 28 Feb 2008 18:24:59 +0000 Paul Howarth wrote: > I've used it after I've done a "make tag" whilst forgetting to commit > changes first, so the tag was applied to the wrong version of the spec > file etc. Force tagging is useful for correcting this error. Couldn't that be solved by making 'make tag' abort if there are unchecked in files in the dir, particularly .spec ? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mikeb at redhat.com Thu Feb 28 18:51:40 2008 From: mikeb at redhat.com (Mike Bonnet) Date: Thu, 28 Feb 2008 13:51:40 -0500 Subject: rebuilding from old cvs tags In-Reply-To: <20080228134552.0995092c@redhat.com> References: <47C4AB74.5010202@redhat.com> <200802261833.18417.dennis@ausil.us> <20080227221548.GA10362@auslistsprd01.us.dell.com> <1204214965.26372.10.camel@burren.boston.redhat.com> <20080228161205.GB11604@nostromo.devel.redhat.com> <1204215457.26372.14.camel@burren.boston.redhat.com> <20080228165843.GA16993@nostromo.devel.redhat.com> <1204219764.26372.23.camel@burren.boston.redhat.com> <20080228182459.0ce9a0c1@metropolis.intra.city-fan.org> <20080228134552.0995092c@redhat.com> Message-ID: <1204224700.26372.36.camel@burren.boston.redhat.com> On Thu, 2008-02-28 at 13:45 -0500, Jesse Keating wrote: > On Thu, 28 Feb 2008 18:24:59 +0000 > Paul Howarth wrote: > > > I've used it after I've done a "make tag" whilst forgetting to commit > > changes first, so the tag was applied to the wrong version of the spec > > file etc. Force tagging is useful for correcting this error. > > Couldn't that be solved by making 'make tag' abort if there are > unchecked in files in the dir, particularly .spec ? It already should. "make tag" uses "cvs tag -c". $ cvs -H tag Usage: cvs tag [-bcdFflR] [-r rev|-D date] tag [files...] -c Check that working files are unmodified. From notting at redhat.com Thu Feb 28 20:21:51 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 28 Feb 2008 15:21:51 -0500 Subject: rebuilding from old cvs tags In-Reply-To: <1204219764.26372.23.camel@burren.boston.redhat.com> References: <47C4AB74.5010202@redhat.com> <200802261833.18417.dennis@ausil.us> <20080227221548.GA10362@auslistsprd01.us.dell.com> <1204214965.26372.10.camel@burren.boston.redhat.com> <20080228161205.GB11604@nostromo.devel.redhat.com> <1204215457.26372.14.camel@burren.boston.redhat.com> <20080228165843.GA16993@nostromo.devel.redhat.com> <1204219764.26372.23.camel@burren.boston.redhat.com> Message-ID: <20080228202150.GA27836@nostromo.devel.redhat.com> Mike Bonnet (mikeb at redhat.com) said: > > Actually, do we even know if disabling force tag can be worked around? > > Not sure what you're asking here. There's no reason force-tag is > required for any part of the package maintenance workflow. I mean, "even if you remove force-tag from the Makefile, you can still move the tag yourself". Which I'm fairly sure you can do. Bill From a.badger at gmail.com Thu Feb 28 20:23:46 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 28 Feb 2008 12:23:46 -0800 Subject: rebuilding from old cvs tags In-Reply-To: <1204224700.26372.36.camel@burren.boston.redhat.com> References: <47C4AB74.5010202@redhat.com> <200802261833.18417.dennis@ausil.us> <20080227221548.GA10362@auslistsprd01.us.dell.com> <1204214965.26372.10.camel@burren.boston.redhat.com> <20080228161205.GB11604@nostromo.devel.redhat.com> <1204215457.26372.14.camel@burren.boston.redhat.com> <20080228165843.GA16993@nostromo.devel.redhat.com> <1204219764.26372.23.camel@burren.boston.redhat.com> <20080228182459.0ce9a0c1@metropolis.intra.city-fan.org> <20080228134552.0995092c@redhat.com> <1204224700.26372.36.camel@burren.boston.redhat.com> Message-ID: <47C71852.3020608@gmail.com> Mike Bonnet wrote: > On Thu, 2008-02-28 at 13:45 -0500, Jesse Keating wrote: >> On Thu, 28 Feb 2008 18:24:59 +0000 >> Paul Howarth wrote: >> >>> I've used it after I've done a "make tag" whilst forgetting to commit >>> changes first, so the tag was applied to the wrong version of the spec >>> file etc. Force tagging is useful for correcting this error. >> Couldn't that be solved by making 'make tag' abort if there are >> unchecked in files in the dir, particularly .spec ? > > It already should. "make tag" uses "cvs tag -c". > > $ cvs -H tag > Usage: cvs tag [-bcdFflR] [-r rev|-D date] tag [files...] > > -c Check that working files are unmodified. > Related, I've sometimes used force when I forgot to check in a patch on a certain branch. Unfortunately, those aren't as easy to check for as modified working files. (Forgetting to update the sources and .cvsignore files falls into a similar category but my current method of updating makes that happen infrequently.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mikeb at redhat.com Thu Feb 28 20:45:44 2008 From: mikeb at redhat.com (Mike Bonnet) Date: Thu, 28 Feb 2008 15:45:44 -0500 Subject: rebuilding from old cvs tags In-Reply-To: <20080228202150.GA27836@nostromo.devel.redhat.com> References: <47C4AB74.5010202@redhat.com> <200802261833.18417.dennis@ausil.us> <20080227221548.GA10362@auslistsprd01.us.dell.com> <1204214965.26372.10.camel@burren.boston.redhat.com> <20080228161205.GB11604@nostromo.devel.redhat.com> <1204215457.26372.14.camel@burren.boston.redhat.com> <20080228165843.GA16993@nostromo.devel.redhat.com> <1204219764.26372.23.camel@burren.boston.redhat.com> <20080228202150.GA27836@nostromo.devel.redhat.com> Message-ID: <1204231544.26372.41.camel@burren.boston.redhat.com> On Thu, 2008-02-28 at 15:21 -0500, Bill Nottingham wrote: > Mike Bonnet (mikeb at redhat.com) said: > > > Actually, do we even know if disabling force tag can be worked around? > > > > Not sure what you're asking here. There's no reason force-tag is > > required for any part of the package maintenance workflow. > > I mean, "even if you remove force-tag from the Makefile, you can still > move the tag yourself". Which I'm fairly sure you can do. We can make tags really immutable by adding a taginfo script to Fedora CVS, and "exit 1" when a "mov" operation (tag -F) is requested. This is essentially the way we prevent the same tag from being applied on multiple branches today. From paul at city-fan.org Fri Feb 29 09:05:51 2008 From: paul at city-fan.org (Paul Howarth) Date: Fri, 29 Feb 2008 09:05:51 +0000 Subject: rebuilding from old cvs tags In-Reply-To: <1204224700.26372.36.camel@burren.boston.redhat.com> References: <47C4AB74.5010202@redhat.com> <200802261833.18417.dennis@ausil.us> <20080227221548.GA10362@auslistsprd01.us.dell.com> <1204214965.26372.10.camel@burren.boston.redhat.com> <20080228161205.GB11604@nostromo.devel.redhat.com> <1204215457.26372.14.camel@burren.boston.redhat.com> <20080228165843.GA16993@nostromo.devel.redhat.com> <1204219764.26372.23.camel@burren.boston.redhat.com> <20080228182459.0ce9a0c1@metropolis.intra.city-fan.org> <20080228134552.0995092c@redhat.com> <1204224700.26372.36.camel@burren.boston.redhat.com> Message-ID: <47C7CAEF.3060001@city-fan.org> Mike Bonnet wrote: > On Thu, 2008-02-28 at 13:45 -0500, Jesse Keating wrote: >> On Thu, 28 Feb 2008 18:24:59 +0000 >> Paul Howarth wrote: >> >>> I've used it after I've done a "make tag" whilst forgetting to commit >>> changes first, so the tag was applied to the wrong version of the spec >>> file etc. Force tagging is useful for correcting this error. >> Couldn't that be solved by making 'make tag' abort if there are >> unchecked in files in the dir, particularly .spec ? > > It already should. "make tag" uses "cvs tag -c". > > $ cvs -H tag > Usage: cvs tag [-bcdFflR] [-r rev|-D date] tag [files...] > > -c Check that working files are unmodified. Well it's been a while since I last made that mistake ;-) Paul. From williams at redhat.com Fri Feb 29 15:58:35 2008 From: williams at redhat.com (Clark Williams) Date: Fri, 29 Feb 2008 09:58:35 -0600 Subject: cache plugin behavior? Message-ID: <47C82BAB.4080705@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael, I was looking at BZ 233529 on mock and was wondering if the requested behavior seems valid (it does to me, just wanted a sanity check). As far as I can tell, the only time the root cache is invalidated is when it ages out (was looking at the plugin). Does it make sense to also invalidate the cache when the .cfg that defines it has a newer modification time? Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfIK6sACgkQHyuj/+TTEp1sxACg4cOB0uX5lsBSwprCenpVIVCS FnMAniBN93OFe9gf6znQreK26yzcB0b9 =Peks -----END PGP SIGNATURE----- From Michael_E_Brown at dell.com Fri Feb 29 16:12:13 2008 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 29 Feb 2008 10:12:13 -0600 Subject: cache plugin behavior? In-Reply-To: <47C82BAB.4080705@redhat.com> References: <47C82BAB.4080705@redhat.com> Message-ID: <20080229161213.GA755@localhost.localdomain> On Fri, Feb 29, 2008 at 09:58:35AM -0600, Clark Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael, > > I was looking at BZ 233529 on mock and was wondering if the requested behavior seems > valid (it does to me, just wanted a sanity check). > > As far as I can tell, the only time the root cache is invalidated is when it ages out > (was looking at the plugin). This is correct. > Does it make sense to also invalidate the cache when the > .cfg that defines it has a newer modification time? Makes perfect sense. May be somewhat difficult to implement, I'm not sure we store the config file name anywhere that the plugin can get to it. -- Michael From williams at redhat.com Fri Feb 29 18:00:45 2008 From: williams at redhat.com (Clark Williams) Date: Fri, 29 Feb 2008 12:00:45 -0600 Subject: cache plugin behavior? In-Reply-To: <20080229161213.GA755@localhost.localdomain> References: <47C82BAB.4080705@redhat.com> <20080229161213.GA755@localhost.localdomain> Message-ID: <47C8484D.3040405@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael E Brown wrote: > On Fri, Feb 29, 2008 at 09:58:35AM -0600, Clark Williams wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Michael, >> >> I was looking at BZ 233529 on mock and was wondering if the requested behavior seems >> valid (it does to me, just wanted a sanity check). >> >> As far as I can tell, the only time the root cache is invalidated is when it ages out >> (was looking at the plugin). > > This is correct. > >> Does it make sense to also invalidate the cache when the >> .cfg that defines it has a newer modification time? > > Makes perfect sense. May be somewhat difficult to implement, I'm not > sure we store the config file name anywhere that the plugin can get to > it. Ok, that's what I was trying to get to when I was looking at the plugin. There's probably something we can stash in the root object that the plugin can get to, maybe even the full path of the config file. My thought is that if we can get the config path, it's just stat'ing it and comparing the modification times. I'll poke at it a bit. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfISE0ACgkQHyuj/+TTEp2AFgCfXOB3gAHBokYqSra6byPe7qsz R6sAn1kciphuenG3Cu8lsDAcWsxJbxZV =faMP -----END PGP SIGNATURE----- From williams at redhat.com Fri Feb 29 19:58:16 2008 From: williams at redhat.com (Clark Williams) Date: Fri, 29 Feb 2008 13:58:16 -0600 Subject: cache plugin behavior? In-Reply-To: <20080229161213.GA755@localhost.localdomain> References: <47C82BAB.4080705@redhat.com> <20080229161213.GA755@localhost.localdomain> Message-ID: <47C863D8.4070709@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael E Brown wrote: > On Fri, Feb 29, 2008 at 09:58:35AM -0600, Clark Williams wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Michael, >> >> I was looking at BZ 233529 on mock and was wondering if the requested behavior seems >> valid (it does to me, just wanted a sanity check). >> >> As far as I can tell, the only time the root cache is invalidated is when it ages out >> (was looking at the plugin). > > This is correct. > >> Does it make sense to also invalidate the cache when the >> .cfg that defines it has a newer modification time? > > Makes perfect sense. May be somewhat difficult to implement, I'm not > sure we store the config file name anywhere that the plugin can get to > it. > -- > Michael Here's a way to do it. One thing that wasn't immediately apparent to me, but became clear when I started installing/debugging was that everytime you install a new mock rpm, the cfg file will have a timestamp newer than any existing root-cache file, which means with this patch each root-cache will be rebuilt. This seems like a reasonable thing to do (rebuild the caches after installing a new mock), but I wonder if it will break anything? Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfIY9cACgkQHyuj/+TTEp07nwCeMSIqBL3c8g9BXmr+BisitT2B g50An2nDwD5xbJ+Nh6Or/ZDDuWwMecxt =Ht8F -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cache-mod.patch URL: From williams at redhat.com Fri Feb 29 21:13:10 2008 From: williams at redhat.com (Clark Williams) Date: Fri, 29 Feb 2008 15:13:10 -0600 Subject: cache plugin behavior? In-Reply-To: <47C863D8.4070709@redhat.com> References: <47C82BAB.4080705@redhat.com> <20080229161213.GA755@localhost.localdomain> <47C863D8.4070709@redhat.com> Message-ID: <47C87566.8030807@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Clark Williams wrote: > Michael E Brown wrote: >> On Fri, Feb 29, 2008 at 09:58:35AM -0600, Clark Williams wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Michael, >>> >>> I was looking at BZ 233529 on mock and was wondering if the requested behavior seems >>> valid (it does to me, just wanted a sanity check). >>> >>> As far as I can tell, the only time the root cache is invalidated is when it ages out >>> (was looking at the plugin). >> This is correct. > >>> Does it make sense to also invalidate the cache when the >>> .cfg that defines it has a newer modification time? >> Makes perfect sense. May be somewhat difficult to implement, I'm not >> sure we store the config file name anywhere that the plugin can get to >> it. >> -- >> Michael > > Here's a way to do it. > > One thing that wasn't immediately apparent to me, but became clear when I started > installing/debugging was that everytime you install a new mock rpm, the cfg file will > have a timestamp newer than any existing root-cache file, which means with this patch > each root-cache will be rebuilt. This seems like a reasonable thing to do (rebuild > the caches after installing a new mock), but I wonder if it will break anything? > > Clark > Michael, Following our IRC conversation, where you expressed admiration and unreserved joy at the ability to update the cache after an install (maybe I overstate a bit), I modified the patch to check the timestamp of both the config file and the site-default.cfg file. I think this does the job in that after an install, the cache is rebuilt because of an updated site-defaults.cfg and if you touch the config file it's also detected. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfIdWYACgkQHyuj/+TTEp1mFQCg2Ckelz5scAG73j+nSBJxxzS2 2cAAoN60hJOAcBF0x1UlFxWVtQM9M1pt =Vutc -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cache-mod-take2.patch URL: