DW> Dan Williams <dcbw@redhat.com> wrote on 07/17/2006 06:11:34 AM:

JT> > On Sun, 2006-07-16 at 12:18 -0400, Joe Todaro wrote:

JT> > Regardless, though, I still don't see any variable
JT> > in /usr/bin/plague-server that has *anything* to

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.  


And indeed was successfully applied against
/usr/share/plague/server/Config.py on July 15;
one line got updated.    

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>


No apology necessary - my misunderstanding. Also, thanks for the
excellent clarification/insight.

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,

DW> because the server will use those to depsolve.

Absolutely, we do care about depsolving..

So, when you say "everything", does that also include (for example)
'i686' now, too, regardless of the fact that i686 is still only a
sub-architecture?

(Hmm, I wouldn't think so..but I just need to be clear on this.)

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

JT> >

DW> I'm getting slightly confused here.

Sorry for that - my fault.

DW> Plague 0.4.3 was building this
DW> package correctly as an i686 package?


No, plague 0.4.3 was building this package correctly as
a 'noarch'; it never tried building as an 'i686' package
until *after* I applied the one-liner patch to
/usr/share/plague/server/Config.py on July 15;  Moreover,
it started doing so (building i686) automatically, because
PackageJob.py is now setting
"archlist = ['i386', 'i686']" rather than
just "archlist = ['i386'] which it has always done in
the past using plague-0.4.

DW> Do you really _want_ this to
DW> build as an i686 package?  


No, of course not - this is a noarch only package, and always
has been.

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?


'noarch' as is specified in the specfile.

JT> > ======================================
JT> > Excerpt from lnxaddons-100-install.cfg
JT> > ======================================
JT> >
JT> > -----------<snip>------------  
JT> > [Arches]
JT> > base_arches=i386
JT> > optional_arches=i686 noarch

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.  


Nope - no such luck; I have removed 'noarch' from 'optional_arches',
re-tested, and am still seeing that same error..

(Jeez, I feel like we're soo close..I can taste it.)

And now I have a design-related question if I may:
Why is the PackageJob.py module appending 'optional_arches'
onto the 'archlist' list (lines 574-576), and later trying
to process those "optional" arches as is they were "base"
arches?  

Hmm, *I* don't get it.. just when I thought
things were starting to make sense too. (:  

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>

I think we're *real* close..  

Regards,
Joe
====================== COMPLETE THREAD =============================

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
>
>