koji-shadow strategy

[Dan Horák]

here are few of my thoughts before starting koji-shadow
- need to ask dgilmore for the package list that are expected to be
missing on ppc/ppc64 (ExcludeArch/ExclusiveArch), he has a script for
that
- because the difference between primary and ppc is so large and there
were mass rebuilds of all python (for 2.7) and perl (for 5.12) packages,
we shouldn't use the "import-noarch" feature, too new packages would be
available in the buildroots causing broken dependencies (the
"prefer-new" feature is needed to include fixed builds)
- the injected packages, that do not exist in primary koji, should have
<your_initials>.X suffix in the Release field, so they are later easily
identified
- should we really start koji-shadow against dist-f15 or should we start
with dist-f14 first even without an intention to be complete, just to
shorten the gap before starting dist-f15

Additions, opinions?


Dan

[Karsten Hopp]

  Am 03.01.2011 15:46, schrieb Dan Horák:
>  here are few of my thoughts before starting koji-shadow
>  - need to ask dgilmore for the package list that are expected to be
>  missing on ppc/ppc64 (ExcludeArch/ExclusiveArch), he has a script for
>  that
>  - because the difference between primary and ppc is so large and there
>  were mass rebuilds of all python (for 2.7) and perl (for 5.12) packages,
>  we shouldn't use the "import-noarch" feature, too new packages would be
>  available in the buildroots causing broken dependencies (the
>  "prefer-new" feature is needed to include fixed builds)
>  - the injected packages, that do not exist in primary koji, should have
>  <your_initials>.X suffix in the Release field, so they are later easily
>  identified
>  - should we really start koji-shadow against dist-f15 or should we start
>  with dist-f14 first even without an intention to be complete, just to
>  shorten the gap before starting dist-f15
>
>  Additions, opinions?
>
>
>  Dan 
python and perl will be a big mess anyway, I think we should update 
them, import the noarch packages afterwards and fix what whatever we 
broke by doing it that way.

+100 to the suggestion that package with some patches that don't exist 
in primary koji should have your initials in the release field.
  We've done that on s390x and it helped a lot to keep track of those 
packages until the patches got into the packages on the primary archs.

I'd rather concentrate on F15 than filling the web-interface with F14 
failures. For some packages it might be worth building the F14 package 
requirements, but that should be done depending on the problem, not for 
all packages.


    Karsten

[Adrian Reber]

On Mon, Jan 03, 2011 at 04:28:45PM +0100, Karsten Hopp wrote:
>   Am 03.01.2011 15:46, schrieb Dan Horák:
>  >here are few of my thoughts before starting koji-shadow
>  >- need to ask dgilmore for the package list that are expected to be
>  >missing on ppc/ppc64 (ExcludeArch/ExclusiveArch), he has a script for
>  >that
>  >- because the difference between primary and ppc is so large and there
>  >were mass rebuilds of all python (for 2.7) and perl (for 5.12) packages,
>  >we shouldn't use the "import-noarch" feature, too new packages would
> be
>  >available in the buildroots causing broken dependencies (the
>  >"prefer-new" feature is needed to include fixed builds)
>  >- the injected packages, that do not exist in primary koji, should have
>  ><your_initials>.X suffix in the Release field, so they are later easily
>  >identified
>  >- should we really start koji-shadow against dist-f15 or should we start
>  >with dist-f14 first even without an intention to be complete, just to
>  >shorten the gap before starting dist-f15
>  >
>  
>  python and perl will be a big mess anyway, I think we should update
>  them, import the noarch packages afterwards and fix what whatever we
>  broke by doing it that way. 
I can confirm that python and perl are a big mess. I just did exactly
that for my local f15 ppc rebuild in mock. I would be willing to do it
again.

>  +100 to the suggestion that package with some patches that don't
>  exist in primary koji should have your initials in the release
>  field.
>   We've done that on s390x and it helped a lot to keep track of those
>  packages until the patches got into the packages on the primary
>  archs. 
How do you inject a package in koji. I can do a scratch build from a
SRPM but it will not build from a SRPM without the "--scratch" option.

		Adrian

[Josh Boyer]

On Wed, Jan 5, 2011 at 7:54 AM, Adrian Reber <adrian(a)lisas.de&gt; wrote:
> > +100 to the suggestion that package with some patches that
> don't
> > exist in primary koji should have your initials in the release
> > field.
> >  We've done that on s390x and it helped a lot to keep track of those
> > packages until the patches got into the packages on the primary
> > archs.
>
>  How do you inject a package in koji. I can do a scratch build from a
>  SRPM but it will not build from a SRPM without the "--scratch" option. 
Your ID has to be an admin in the hub to do SRPM builds or raw
RPM/SRPM imports.  Right now the admins are me, Karsten, Dan, and
Dennis.  You obviously care and are putting forth effort, so I
wouldn't be opposed to granting you admin if the others agree.

josh

[Dan Horák]

Josh Boyer píše v St 05. 01. 2011 v 08:03 -0500: 
>  On Wed, Jan 5, 2011 at 7:54 AM, Adrian Reber <adrian(a)lisas.de&gt;
> wrote:
>  >> +100 to the suggestion that package with some patches that don't
>  >> exist in primary koji should have your initials in the release
>  >> field.
>  >>  We've done that on s390x and it helped a lot to keep track of those
>  >> packages until the patches got into the packages on the primary
>  >> archs.
>  >
>  > How do you inject a package in koji. I can do a scratch build from a
>  > SRPM but it will not build from a SRPM without the "--scratch" option.
>  
>  Your ID has to be an admin in the hub to do SRPM builds or raw
>  RPM/SRPM imports.  Right now the admins are me, Karsten, Dan, and
>  Dennis.  You obviously care and are putting forth effort, so I
>  wouldn't be opposed to granting you admin if the others agree. 
No objections to adding Adrian as admin here too, just ask on IRC or
here if unsure about the right actions.


Dan