<tt>DW> Dan Williams <dcbw@redhat.com> wrote on 07/17/2006 06:11:34 AM: </tt> <tt>JT> > On Sun, 2006-07-16 at 12:18 -0400, Joe Todaro wrote:</tt> <tt>JT> > Regardless, though, I still don't see any variable JT> > in /usr/bin/plague-server that has *anything* to </tt> <tt>JT> > with "optional arches" or "base arches", which JT> > is what the patch was for right? DW> DW> The patch would actually have been DW> against /usr/share/plague/server/Config.py. </tt> <tt>And indeed was successfully applied against </tt> <tt>/usr/share/plague/server/Config.py on July 15; </tt> <tt>one line got updated. </tt> <tt>DW> That's where it gets DW> somewhat confusing, since in the build directory everything is together, DW> but during RPM creation and install the server's main.py file gets DW> renamed to /usr/bin/plague-server. What I've said 'plague-server', I've DW> generally been referring to the server process as a whole, not specific DW> files. Sorry for that. DW></tt> <tt>No apology necessary - my misunderstanding. Also, thanks for the </tt> <tt>excellent clarification/insight.</tt> <tt>DW> and on the server, which has _no_ architecture at all, you'd have DW> in /etc/plague/server/targets: DW> DW> fedora-devel-core.cfg DW> fedora-5-core.cfg DW> fedora-4-core.cfg DW> fedora-devel-extras.cfg DW> fedora-5-extras.cfg DW> fedora-4-extras.cfg DW> DW> and on the server, if you care about depsolving (ie if you have the DW> "depsolve_jobs = yes" set in /etc/plague/server/plague-server.cfg) then DW> you actually do need mock target configs for everything too,</tt> <tt>DW> because the server will use those to depsolve.</tt> <tt>Absolutely, we do care about depsolving..</tt> <tt>So, when you say "everything", does that also include (for example) </tt> <tt>'i686' now, too, regardless of the fact that i686 is still only a </tt> <tt>sub-architecture? </tt> <tt>(Hmm, I wouldn't think so..but I just need to be clear on this.) </tt> <tt>JT> > ======================== JT> > Excerpt from WhoAmI.spec JT> > ======================== JT> > JT> > -----------<snip>------------ JT> > %define rversion 4.00 JT> > %define rel 9 JT> > %define pkgname WhoAmI JT> > JT> > Summary : %{__distribution_long} system information JT> > Name : %{pkgname} JT> > Version : %{rversion} JT> > Release : %{rel}_%{__build_distribution}%{__build_release} JT> > License : %__spec_internal_license JT> > Group : System Environment/Base JT> > Url : %__repository_url JT> > JT> > Packager : %{packager} JT> > JT> > Source0 : %{pkgname}.tar.gz JT> > JT> > %if %__build_rhel JT> > Requires : coreutils, bash, python, grep, rpm JT> > %endif JT> > JT> > %if %__build_suse JT> > Requires : coreutils, bash, aaa_base, python, grep, rpm JT> > %endif JT> > JT> > BuildArch : noarch </tt> <tt>JT> ></tt> <tt>DW> I'm getting slightly confused here. </tt> <tt>Sorry for that - my fault.</tt> <tt>DW> Plague 0.4.3 was building this DW> package correctly as an i686 package?</tt> <tt>No, plague 0.4.3 was building this package correctly as </tt> <tt>a 'noarch'; it never tried building as an 'i686' package</tt> <tt>until *after* I applied the one-liner patch to </tt> <tt>/usr/share/plague/server/Config.py on July 15; Moreover,</tt> <tt>it started doing so (building i686) automatically, because</tt> <tt>PackageJob.py is now setting </tt> <tt>"archlist = ['i386', 'i686']" rather than</tt> <tt>just "archlist = ['i386'] which it has always done in </tt> <tt>the past using plague-0.4.</tt> <tt>DW> Do you really _want_ this to DW> build as an i686 package? </tt> <tt>No, of course not - this is a noarch only package, and always</tt> <tt>has been. </tt> <tt>DW> If so, I think the "BuildArch: noarch" is DW> wrong then. Typically, if you want a package to build noarch, you DW> specify "BuildArch: noarch" and it will then only build on noarch. What DW> arch is this package supposed to be for, exactly?</tt> <tt>'noarch' as is specified in the specfile. </tt> <tt>JT> > ====================================== JT> > Excerpt from lnxaddons-100-install.cfg JT> > ====================================== JT> > JT> > -----------<snip>------------ JT> > [Arches] JT> > base_arches=i386 JT> > optional_arches=i686 noarch </tt> <tt>JT> > GW> Ok; I think this is the cause of the noarch problem. Since 'noarch' is GW> a base architecture in itself, you don't need it in optional_arches. If GW> you remove it, I think things will work as you expect. </tt> <tt>Nope - no such luck; I have removed 'noarch' from 'optional_arches', </tt> <tt>re-tested, and am still seeing that same error.. </tt> <tt>(Jeez, I feel like we're soo close..I can taste it.)</tt> <tt>And now I have a design-related question if I may: </tt> <tt>Why is the PackageJob.py module appending 'optional_arches'</tt> <tt>onto the 'archlist' list (lines 574-576), and later trying </tt> <tt>to process those "optional" arches as is they were "base" </tt> <tt>arches? </tt> <tt>Hmm, *I* don't get it.. just when I thought </tt> <tt>things were starting to make sense too. (: </tt> <tt>CW> Every builder GW> can build a 'noarch' package, so that architecture is essentially added GW> by default and you don't need to do anything explicit for it. Yay for GW> documentation (or complete lack of it). GW> GW> However, this does expose a bug. If an architecture is listed in GW> optional_arches, it shouldn't actually be used by a package build unless GW> the package was going to build for noarch already. GW> </tt> <tt>I think we're *real* close.. </tt> Regards, Joe ====================== COMPLETE THREAD ============================= <tt>Dan Williams <dcbw@redhat.com> wrote on 07/17/2006 06:11:34 AM: > On Sun, 2006-07-16 at 12:18 -0400, Joe Todaro wrote: > > > > Dan Williams <dcbw@redhat.com> wrote on 07/16/2006 10:41:55 AM: > > > > > On Sun, 2006-07-16 at 09:48 -0400, Joe Todaro wrote: > > > > > > > > Thanks Dan. > > > > > > > > So I ran a quick regression test, just to make sure that *i386* is > > > > still working, but, it *failed* ... (also note that i686 gave > > > > basically the same errors..) > > > > > > > > SEE BELOW for *regression* test results, both BEFORE and AFTER > > > > applying patch 'plague-opt-arches-fix.patch' to server/Config.py. > > I > > > > repeated that test sequence several times, by the way. Also, I > > was > > > > surprised to see that 'WhoAmI' was trying to build as an 'i686' > > rpm > > > > rather than a 'noarch' which is what it really is. So, since I > > can't > > > > > > Hmm... Building an i386 package worked for me when I tested it with > > > current CVS HEAD, as did an i686 package. > > > > Do you think that re-installing plague-0.5 from scratch (rpm -e/rpm > > -ivh) might help? > > If so, are there any "gotchas" I need to be aware of? > > But hopefully this won't be necessary. > > Hmm, this likely wouldn't change much. > > > But also I have a question: Since i686 is a "subarch" of i386, do I > > need > > to create any target config files specicially for i686, such as in > > the > > following directories: > > - /etc/plague/server/targets > > - /etc/plague/builder/targets > > - /etc/mock > > No, you shouldn't need to create target configs for that. Only for > 'base' architectures like i386, ppc, ppc64, x86_64, sparc, sparc64, etc. > Sub-architectures like i686, em64t, sparcv9, etc, don't need their own > target configs. > > For the builder, you need one target config for every "repository" that > builder will be able to support. For example, if the machine were an > x86-64-class machine able to build Fedora Core and Fedora Extras, you'd > have in /etc/plague/builder/targets: > > fedora-devel-i386-core.cfg > fedora-5-i386-core.cfg > fedora-4-i386-core.cfg > fedora-devel-i386-extras.cfg > fedora-5-i386-extras.cfg > fedora-4-i386-extras.cfg > fedora-devel-x86_64-core.cfg > fedora-5-x86_64-core.cfg > ... > > and on the server, which has _no_ architecture at all, you'd have > in /etc/plague/server/targets: > > fedora-devel-core.cfg > fedora-5-core.cfg > fedora-4-core.cfg > fedora-devel-extras.cfg > fedora-5-extras.cfg > fedora-4-extras.cfg > > and on the server, if you care about depsolving (ie if you have the > "depsolve_jobs = yes" set in /etc/plague/server/plague-server.cfg) then > you actually do need mock target configs for everything too, because the > server will use those to depsolve. > > > > Coming back to the original question, optional_arches gives > > buildsystem > > > administrators a filter on arches to build. For example, Fedora > > Extras > > > doesn't necessarily want to allow packages to be built for i486, > > even if > > > the RPM requests it, because we don't support i486. So if you add > > i686 > > > to 'optional_arches', then packages that request to be built for > > i686 > > > with ExclusiveArch will be allowed to build for i686, otherwise not. > > > > > > > I'm also really clear on this, too, now. Well, at least this proves, > > to > > me anyway, that I've had a pretty decent understanding of how things > > work > > all along -- thanks to the great description you gave above, of > > course. > > No problem. There's so many options to stuff like RPM and apt/dpkg that > it's hard to keep straight. > > > > > Also, could you please explain/elaborate when you say: "Patch > > attached > > > > that should apply against an installed copy of plague-server as > > > > well." > > > > Um, your patch is clearly intended to update file server/Config.py > > > > file, so I really don't understand how I can also use *it* to > > update > > > > file *plague-server* (/usr/bin/plague-server?) as well, which > > appears > > > > to be a start-up script -- am I missing something here? > > > > > > I had meant to change the paths such that you could apply the patch > > > from / using patch -p0 or such; I did that and then re-diffed and > > likely > > > forgot to update the patch bits again. Since the 'cvs diff' is > > rooted > > > at a different directory than the installed plague server directory, > > I > > > was trying to make life simpler for you. My bad. > > > > > > > Oh, cool, I've never done that before - thanks. > > > > Regardless, though, I still don't see any variable > > in /usr/bin/plague-server > > that has *anything* to with "optional arches" or "base arches", which > > is > > what the patch was for right? > > The patch would actually have been > against /usr/share/plague/server/Config.py. That's where it gets > somewhat confusing, since in the build directory everything is together, > but during RPM creation and install the server's main.py file gets > renamed to /usr/bin/plague-server. What I've said 'plague-server', I've > generally been referring to the server process as a whole, not specific > files. Sorry for that. > > > > > For the good news (for me anyway), I'm also trying to learn Python > > > > (Diving Into Python) on my own time, so that hopefully one day I > > might > > > > be able help squash some of these bugs.. However, in the meantime, > > > > I/we very much appreciate your help and expertise.. > > > > > > > > REGRESSION TEST RESULTS ARE BELOW... > > > > > > > > Dan Williams <dcbw@redhat.com> wrote on 07/15/2006 01:20:54 PM: > > > > > > > > > On Tue, 2006-07-04 at 09:58 -0400, Joe Todaro wrote: > > > > > > > > > > > > Hi, > > > > > > I'm having a problem *not* being able to build 'i686' packages > > > > (i.e. > > > > > > optional_arches=i686) anymore *after* having upgraded our > > plague > > > > > > server/builder (Opteron x86_64) a couple of weeks ago from > > > > > > plague-0.4.3 to *plague-0.5.0*. The problem happens only with > > i686 > > > > > > (optional_arches=i686) -- not with i386 (base_arches=i386) > > which > > > > > > continues to work flawlessly. > > > > > > > > > > Found and fixed in CVS HEAD. Patch attached that should apply > > > > against > > > > > an installed copy of plague-server as well. Thanks for the > > report, > > > > and > > > > > sorry for the lag. > > > > > > > > > > Cheers, > > > > > Dan > > > > > > > > > > > > > > > [attachment "plague-opt-arches-fix.patch" deleted by Joe > > > > > Todaro/Poughkeepsie/IBM] > > > > > > > > > > > > 626 (WhoAmI): Requesting depsolve... > > > > 626 (WhoAmI): Starting depsolve for arches: ['i386', 'i686', > > > > 'noarch']. > > > > > > Ok; what do you have in the 'optional_arches' for this target? > > > > ====================================== > > Excerpt from lnxaddons-100-install.cfg > > ====================================== > > > > -----------<snip>------------ > > [Arches] > > base_arches=i386 > > optional_arches=i686 noarch > > Ok; I think this is the cause of the noarch problem. Since 'noarch' is > a base architecture in itself, you don't need it in optional_arches. If > you remove it, I think things will work as you expect. Every builder > can build a 'noarch' package, so that architecture is essentially added > by default and you don't need to do anything explicit for it. Yay for > documentation (or complete lack of it). > > However, this does expose a bug. If an architecture is listed in > optional_arches, it shouldn't actually be used by a package build unless > the package was going to build for noarch already. > > > ----------</snip>------------ > > > > > > What do the top bits of the specfile for WhoAmI look like? i.e., > > are > > > there any of the following specfile tags, and what are their values? > > > > > > BuildArch > > > ExclusiveArch > > > ExcludeArch > > > > > > > ======================== > > Excerpt from WhoAmI.spec > > ======================== > > > > -----------<snip>------------ > > %define rversion 4.00 > > %define rel 9 > > %define pkgname WhoAmI > > > > Summary : %{__distribution_long} system information > > Name : %{pkgname} > > Version : %{rversion} > > Release : %{rel}_%{__build_distribution}%{__build_release} > > License : %__spec_internal_license > > Group : System Environment/Base > > Url : %__repository_url > > > > Packager : %{packager} > > > > Source0 : %{pkgname}.tar.gz > > > > %if %__build_rhel > > Requires : coreutils, bash, python, grep, rpm > > %endif > > > > %if %__build_suse > > Requires : coreutils, bash, aaa_base, python, grep, rpm > > %endif > > > > BuildArch : noarch > > I'm getting slightly confused here. Plague 0.4.3 was building this > package correctly as an i686 package? Do you really _want_ this to > build as an i686 package? If so, I think the "BuildArch: noarch" is > wrong then. Typically, if you want a package to build noarch, you > specify "BuildArch: noarch" and it will then only build on noarch. What > arch is this package supposed to be for, exactly? > > Cheers, > Dan > > </tt>