Re: [PATCH] PPC is strange. RHEL provides a 'ppc' tree that is intended only for ppc64 systems (typically IBM PowerPC). Fedora provides a 'ppc' tree that includes ppc32 and ppc64 kernels. Fedora also builds a 'ppc64' tree which contains *only* ppc64

[Javier Palacios]

On Tue, Nov 18, 2008 at 3:53 PM, James Laska <jlaska(a)redhat.com&gt; wrote:
>  The included changes add support for a new architecture
> 'ppc64'.  Any cobbler imports on a ppc tree will detect and add the appropriate
> distro's and profiles for the ppc32 or ppc64 if applicable.  For example:
>
>  $ cobbler import --name rawhide --path /mnt/rawhide/nightly/rawhide-20081113/ppc/os
> --available-as http://gromit.redhat.com/pub/fedora/linux/development/ppc/os
>  [...]
>  ---------------- (associating kickstarts)
>  - found content (breed=redhat) at /mnt/rawhide/nightly/rawhide-20081113/ppc/os/ppc/ppc32
>  --os-version for breed redhat must be one of rhel2.1, rhel3, rhel4, rhel5, fedora5,
> fedora6, fedora7, fedora8, fedora9, fedora10, generic24, generic26, other, given was rhel9
I don't believe it is related to your problem, but rawhide could
produce problems. There are two sets of files matching *release-*, and
in any case you probably need to add something to codes.py.

I cannot do anything with RedHat, but I will try the fedora9/rawhide.
It looks that there is something now working well in the import code,
and I wanted to check a debian powerpc import in any case.

Javier Palacios

[PATCH] PPC is strange. RHEL provides a 'ppc' tree that is intended only for ppc64 systems (typically IBM PowerPC). Fedora provides a 'ppc' tree that includes ppc32 and ppc64 kernels. Fedora also builds a 'ppc64' tree which contains *only* ppc64

[James Laska]

On Tue, 2008-11-18 at 21:34 +0100, Javier Palacios wrote:
>  On Tue, Nov 18, 2008 at 3:53 PM, James Laska
> <jlaska(a)redhat.com&gt; wrote:
>  > The included changes add support for a new architecture 'ppc64'.  Any
> cobbler imports on a ppc tree will detect and add the appropriate distro's and
> profiles for the ppc32 or ppc64 if applicable.  For example:
>  >
>  > $ cobbler import --name rawhide --path /mnt/rawhide/nightly/rawhide-20081113/ppc/os
> --available-as http://gromit.redhat.com/pub/fedora/linux/development/ppc/os
>  > [...]
>  > ---------------- (associating kickstarts)
>  > - found content (breed=redhat) at
> /mnt/rawhide/nightly/rawhide-20081113/ppc/os/ppc/ppc32
>  > --os-version for breed redhat must be one of rhel2.1, rhel3, rhel4, rhel5, fedora5,
> fedora6, fedora7, fedora8, fedora9, fedora10, generic24, generic26, other, given was
> rhel9
>  
>  I don't believe it is related to your problem, but rawhide could
>  produce problems. There are two sets of files matching *release-*, and
>  in any case you probably need to add something to codes.py. 
Sorry, coming up to speed on this now.  So it appears that the
fedora-release and generic-release packages (each with different
version :( ) are confusing cobbler during import.  

For example (with debugging enabled):

# cobbler import --name rawhide --path /mnt/rawhide/nightly/rawhide-20081113/i386/os
--available-as http://gromit.redhat.com/pub/fedora/linux/development/i386/os
---------------- (adding distros)
- found content (breed=redhat) at
/mnt/rawhide/nightly/rawhide-20081113/i386/os/images/pxeboot
- creating new distro: rawhide-i386
- creating new profile: rawhide-i386
- creating new profile: rescue-rawhide-i386
---------------- (associating kickstarts)
- found content (breed=redhat) at
/mnt/rawhide/nightly/rawhide-20081113/i386/os/images/pxeboot
- processing rpm : fedora-release-10-1.noarch.rpm

- finding default kickstart template for fedora 10.0
fedora10, /etc/cobbler/sample_end.ks = importer.set_variance(fedora, 10.0, 1.0, i386)

- processing rpm : generic-release-9.91-2.noarch.rpm
- finding default kickstart template for redhat 9.0
rhel9, /etc/cobbler/sample.ks = importer.set_variance(redhat, 9.0, 91.0, i386)

--os-version for breed redhat must be one of rhel2.1, rhel3, rhel4, rhel5, fedora5,
fedora6, fedora7, fedora8, fedora9, fedora10, generic24, generic26, other, given was
rhel9

I'm not sure of the best approach here.  Should cobbler interpret
generic-release as a fedora release?  Alternatively, should we stop
scanning "*release*rpm" packages once we find a good one (e.g.
redhat-release or fedora-release)?

Thanks,
James

>  I cannot do anything with RedHat, but I will try the
> fedora9/rawhide.
>  It looks that there is something now working well in the import code,
>  and I wanted to check a debian powerpc import in any case.
>  
>  Javier Palacios
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler 
-- 
==========================================
 James Laska         -- jlaska(a)redhat.com
 Quality Engineering -- Red Hat, Inc.
==========================================

[PATCH] PPC is strange. RHEL provides a 'ppc' tree that is intended only for ppc64 systems (typically IBM PowerPC). Fedora provides a 'ppc' tree that includes ppc32 and ppc64 kernels. Fedora also builds a 'ppc64' tree which contains *only* ppc64

[Javier Palacios]

>  - finding default kickstart template for fedora 10.0
>  fedora10, /etc/cobbler/sample_end.ks = importer.set_variance(fedora, 10.0, 1.0, i386)
>
>  - processing rpm : generic-release-9.91-2.noarch.rpm
>  - finding default kickstart template for redhat 9.0
>  rhel9, /etc/cobbler/sample.ks = importer.set_variance(redhat, 9.0, 91.0, i386)
>
>  --os-version for breed redhat must be one of rhel2.1, rhel3, rhel4, rhel5, fedora5,
> fedora6, fedora7, fedora8, fedora9, fedora10, generic24, generic26, other, given was
> rhel9
>
>  I'm not sure of the best approach here.  Should cobbler interpret
>  generic-release as a fedora release?  Alternatively, should we stop
>  scanning "*release*rpm" packages once we find a good one (e.g.
>  redhat-release or fedora-release)? 
Probably is just to modify the glob in get_release_file to match
self.breed + "*release*" instead of just "*release*". I'm trusting
in
memory, so maybe a proper self.breed needs to be created at
ImporterXXX class. And I'm sure than the release glob has a '-'
somewhere. If you understand my explanation and check successfully,
great. If not, I will be able to check that in a few hours.

Javier Palacios

[PATCH] PPC is strange. RHEL provides a 'ppc' tree that is intended only for ppc64 systems (typically IBM PowerPC). Fedora provides a 'ppc' tree that includes ppc32 and ppc64 kernels. Fedora also builds a 'ppc64' tree which contains *only* ppc64

[Javier Palacios]

> > I'm not sure of the best approach here.  Should cobbler
> interpret
> > generic-release as a fedora release?  Alternatively, should we stop
> > scanning "*release*rpm" packages once we find a good one (e.g.
> > redhat-release or fedora-release)? 
Here it is, was more or less as simple as expected, although longer.
I have subclassed the RedHatImporter into a fedora and centos specific,
as the self.breed is somewhat hardcoded. As a side effect the distro
guessing is more specific (hopefully).

My only concern is about which distro has a 'Server' directory under
the media topdir. I've left as "redhat", but if that is not the case, it
might
produce errors and require a change.

Javier Palacios

[PATCH] PPC is strange. RHEL provides a 'ppc' tree that is intended only for ppc64 systems (typically IBM PowerPC). Fedora provides a 'ppc' tree that includes ppc32 and ppc64 kernels. Fedora also builds a 'ppc64' tree which contains *only* ppc64

[Michael DeHaan]

Javier Palacios wrote:
> >> I'm not sure of the best approach here.  Should cobbler
> interpret
> >> generic-release as a fedora release?  Alternatively, should we stop
> >> scanning "*release*rpm" packages once we find a good one (e.g.
> >> redhat-release or fedora-release)?
> >>       
>
>  Here it is, was more or less as simple as expected, although longer.
>  I have subclassed the RedHatImporter into a fedora and centos specific,
>  as the self.breed is somewhat hardcoded. As a side effect the distro
>  guessing is more specific (hopefully).
>
>  My only concern is about which distro has a 'Server' directory under
>  the media topdir. I've left as "redhat", but if that is not the case, it
> might
>  produce errors and require a change.
>
>  Javier Palacios
>    
>  ------------------------------------------------------------------------
>
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>     
I don't see the need for the explicit Fedora and CentOS breeds when they 
share very much in common (all now are born from Fedora and share the 
same structures).

What is the reason for introducing this?

Also, your patch likely breaks Scientific Linux.

--Michael

[PATCH] PPC is strange. RHEL provides a 'ppc' tree that is intended only for ppc64 systems (typically IBM PowerPC). Fedora provides a 'ppc' tree that includes ppc32 and ppc64 kernels. Fedora also builds a 'ppc64' tree which contains *only* ppc64

[Javier Palacios]

>  I don't see the need for the explicit Fedora and CentOS breeds
> when they
>  share very much in common (all now are born from Fedora and share the
>  same structures).
>
>  What is the reason for introducing this? 
Besides the particular fixing of this double *release* file, the same reasons
behind the ubuntu importer. Although the three are quite similar, they have
slight differences. For example, you will have no repodata on RHEL media,
or can do a more specific search for some items, such as the kernel
packages in match_kernelarch_file. And remove the if fedora elif redhat
that exists along the code.

>  Also, your patch likely breaks Scientific Linux. 
More than likely. To really be backwards compatible, the get_release_files
from the RedHatImporter should not be touched, and the new one should
be copied to the fedora and centos importers.

Javier Palacios

[PATCH] PPC is strange. RHEL provides a 'ppc' tree that is intended only for ppc64 systems (typically IBM PowerPC). Fedora provides a 'ppc' tree that includes ppc32 and ppc64 kernels. Fedora also builds a 'ppc64' tree which contains *only* ppc64

[Michael DeHaan]

Javier Palacios wrote:
> > I don't see the need for the explicit Fedora and CentOS
> breeds when they
> > share very much in common (all now are born from Fedora and share the
> > same structures).
> >
> > What is the reason for introducing this?
> >     
>
>  Besides the particular fixing of this double *release* file, the same reasons
>  behind the ubuntu importer. Although the three are quite similar, they have
>  slight differences. For example, you will have no repodata on RHEL media,
>  or can do a more specific search for some items, such as the kernel
>  packages in match_kernelarch_file. And remove the if fedora elif redhat
>  that exists along the code.
>     
I don't want this. The initial reason for --breed's creation is to 
handle distributions that require slightly different kernel arguments.

Existing users will have --breed=redhat and will be confused when they 
search and find some imports tagged
redhat and some fedora/centos.

These are all Red Hat rederived distributions so things can stay as is, 
and we can specifically handle
the generic-release by ignoring it.

>    
> > Also, your patch likely breaks Scientific Linux.
> >     
>
>  More than likely. To really be backwards compatible, the get_release_files
>  from the RedHatImporter should not be touched, and the new one should
>  be copied to the fedora and centos importers.
>     
I'm not going to apply this, so things should stay working. I think this 
keeps things simple and we should not be introducing major
changes to the importer at this time. A simple workaround to ignore 
generic-release is sufficient.


>  Javier Palacios
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>

[PATCH] PPC is strange. RHEL provides a 'ppc' tree that is intended only for ppc64 systems (typically IBM PowerPC). Fedora provides a 'ppc' tree that includes ppc32 and ppc64 kernels. Fedora also builds a 'ppc64' tree which contains *only* ppc64

[Michael DeHaan]

James Laska wrote:
>  On Tue, 2008-11-18 at 21:34 +0100, Javier Palacios wrote:
>    
> > On Tue, Nov 18, 2008 at 3:53 PM, James Laska <jlaska(a)redhat.com&gt; wrote:
> >     
> >> The included changes add support for a new architecture 'ppc64'.  Any
> cobbler imports on a ppc tree will detect and add the appropriate distro's and
> profiles for the ppc32 or ppc64 if applicable.  For example:
> >>
> >> $ cobbler import --name rawhide --path
> /mnt/rawhide/nightly/rawhide-20081113/ppc/os --available-as
> http://gromit.redhat.com/pub/fedora/linux/development/ppc/os
> >> [...]
> >> ---------------- (associating kickstarts)
> >> - found content (breed=redhat) at
> /mnt/rawhide/nightly/rawhide-20081113/ppc/os/ppc/ppc32
> >> --os-version for breed redhat must be one of rhel2.1, rhel3, rhel4, rhel5,
> fedora5, fedora6, fedora7, fedora8, fedora9, fedora10, generic24, generic26, other, given
> was rhel9
> >>       
> > I don't believe it is related to your problem, but rawhide could
> > produce problems. There are two sets of files matching *release-*, and
> > in any case you probably need to add something to codes.py.
> >     
>
>  Sorry, coming up to speed on this now.  So it appears that the
>  fedora-release and generic-release packages (each with different
>  version :( ) are confusing cobbler during import.  
>
>  For example (with debugging enabled):
>
>  # cobbler import --name rawhide --path /mnt/rawhide/nightly/rawhide-20081113/i386/os
> --available-as http://gromit.redhat.com/pub/fedora/linux/development/i386/os
>  ---------------- (adding distros)
>  - found content (breed=redhat) at
> /mnt/rawhide/nightly/rawhide-20081113/i386/os/images/pxeboot
>  - creating new distro: rawhide-i386
>  - creating new profile: rawhide-i386
>  - creating new profile: rescue-rawhide-i386
>  ---------------- (associating kickstarts)
>  - found content (breed=redhat) at
> /mnt/rawhide/nightly/rawhide-20081113/i386/os/images/pxeboot
>  - processing rpm : fedora-release-10-1.noarch.rpm
>
>  - finding default kickstart template for fedora 10.0
>  fedora10, /etc/cobbler/sample_end.ks = importer.set_variance(fedora, 10.0, 1.0, i386)
>
>  - processing rpm : generic-release-9.91-2.noarch.rpm
>  - finding default kickstart template for redhat 9.0
>  rhel9, /etc/cobbler/sample.ks = importer.set_variance(redhat, 9.0, 91.0, i386)
>
>  --os-version for breed redhat must be one of rhel2.1, rhel3, rhel4, rhel5, fedora5,
> fedora6, fedora7, fedora8, fedora9, fedora10, generic24, generic26, other, given was
> rhel9
>
>  I'm not sure of the best approach here.  Should cobbler interpret
>  generic-release as a fedora release?  Alternatively, should we stop
>  scanning "*release*rpm" packages once we find a good one (e.g.
>  redhat-release or fedora-release)?
>
>  Thanks,
>  James
>
>     
Possibly.  I also think we should not respond to generic-release at all.

--Michael