The powerpc secondary arch team has disabled all ppc32 builds in koji for F21 and beyond:
https://lists.fedoraproject.org/pipermail/ppc/2014-May/002801.html
There's little point in keeping support for ppc32 support in the kernel package when it will never be built. This also removes the -smp variant and with_smp* support, as that was only used on ppc32. --- Makefile.config | 12 +--- config-powerpc32-generic | 180 ----------------------------------------------- config-powerpc32-smp | 3 - filter-ppc.sh | 14 ---- kernel.spec | 72 +++---------------- 5 files changed, 10 insertions(+), 271 deletions(-) delete mode 100644 config-powerpc32-generic delete mode 100644 config-powerpc32-smp delete mode 100644 filter-ppc.sh
diff --git a/Makefile.config b/Makefile.config index 3483968..63549f6 100644 --- a/Makefile.config +++ b/Makefile.config @@ -11,11 +11,10 @@ CONFIGFILES = \ $(CFG)-s390x.config \ $(CFG)-armv7hl.config $(CFG)-armv7hl-lpae.config \ $(CFG)-aarch64.config \ - $(CFG)-ppc.config $(CFG)-ppc-smp.config \ $(CFG)-ppc64.config $(CFG)-ppc64p7.config $(CFG)-ppc64-debug.config \ $(CFG)-ppc64le.config
-PLATFORMS = x86 x86_64 powerpc powerpc32 powerpc64 s390x arm arm64 +PLATFORMS = x86 x86_64 powerpc powerpc64 s390x arm arm64 TEMPFILES = $(addprefix temp-, $(addsuffix -generic, $(PLATFORMS)))
configs: $(CONFIGFILES) @@ -81,9 +80,6 @@ temp-powerpc-generic: config-powerpc-generic temp-generic temp-powerpc-debug-generic: config-powerpc-generic temp-debug-generic perl merge.pl $^ > $@
-temp-powerpc32-generic: config-powerpc32-generic temp-powerpc-generic - perl merge.pl $^ > $@ - temp-powerpc64-generic: config-powerpc64 temp-powerpc-generic perl merge.pl $^ > $@
@@ -134,9 +130,3 @@ $(CFG)-armv7hl-lpae.config: /dev/null temp-armv7-lpae
$(CFG)-aarch64.config: /dev/null temp-arm64 perl merge.pl $^ arm64 > $@ - -$(CFG)-ppc.config: /dev/null temp-powerpc32-generic - perl merge.pl $^ powerpc > $@ - -$(CFG)-ppc-smp.config: config-powerpc32-smp temp-powerpc32-generic - perl merge.pl $^ powerpc > $@ diff --git a/config-powerpc32-generic b/config-powerpc32-generic deleted file mode 100644 index 10e02fb..0000000 --- a/config-powerpc32-generic +++ /dev/null @@ -1,180 +0,0 @@ -# CONFIG_SMP is not set -CONFIG_PPC32=y -# CONFIG_PPC64 is not set -# CONFIG_RTAS_PROC is not set -# CONFIG_PCMCIA_M8XX is not set -# CONFIG_HOTPLUG_PCI is not set -CONFIG_CPU_FREQ_PMAC=y -CONFIG_PPC_CHRP=y -CONFIG_PPC_PMAC=y -# CONFIG_PPC_MPC52xx is not set -CONFIG_PPC_PREP=y - -# CONFIG_PPC_MPC5200_SIMPLE is not set -# CONFIG_SATA_FSL is not set -# CONFIG_SATA_NV is not set - -# busted in .28git1 -# ERROR: "cacheable_memzero" [drivers/net/gianfar_driver.ko] undefined! -# CONFIG_GIANFAR is not set -# CONFIG_USB_EHCI_FSL is not set - -CONFIG_PMAC_APM_EMU=y -CONFIG_PMAC_BACKLIGHT=y - -CONFIG_HIGHMEM=y -# CONFIG_HIGHMEM_START_BOOL is not set -# CONFIG_LOWMEM_SIZE_BOOL is not set -# CONFIG_TASK_SIZE_BOOL is not set -# CONFIG_KERNEL_START_BOOL is not set -# CONFIG_PPC601_SYNC_FIX is not set -CONFIG_ADVANCED_OPTIONS=y -CONFIG_SCSI_MESH=m -CONFIG_SCSI_MESH_SYNC_RATE=5 -CONFIG_SCSI_MESH_RESET_DELAY_MS=4000 - -CONFIG_LBDAF=y - -CONFIG_SCSI_MAC53C94=m -CONFIG_ADB_CUDA=y -CONFIG_ADB_MACIO=y -CONFIG_INPUT_ADBHID=y -CONFIG_ADB_PMU_LED=y -CONFIG_ADB_PMU_LED_IDE=y - -CONFIG_PMAC_MEDIABAY=y -CONFIG_NET_VENDOR_APPLE=y -CONFIG_BMAC=m -CONFIG_MACE=m -# CONFIG_MACE_AAUI_PORT is not set -# CONFIG_MV643XX_ETH is not set -CONFIG_I2C_HYDRA=m -CONFIG_I2C_MPC=m -CONFIG_THERM_WINDTUNNEL=m -CONFIG_THERM_ADT746X=m -# CONFIG_ANSLCD is not set - -CONFIG_FB_PLATINUM=y -CONFIG_FB_VALKYRIE=y -CONFIG_FB_CT65550=y -# CONFIG_BDI_SWITCH is not set - -CONFIG_MAC_FLOPPY=m -# CONFIG_BLK_DEV_FD is not set - -CONFIG_FB_ATY128=y -CONFIG_FB_ATY=y -CONFIG_FB_MATROX=y -# CONFIG_KEXEC is not set - -# CONFIG_HVC_RTAS is not set - -# CONFIG_UDBG_RTAS_CONSOLE is not set -CONFIG_BRIQ_PANEL=m - -# CONFIG_ATA_PIIX is not set -# CONFIG_PATA_AMD is not set -# CONFIG_PATA_ATIIXP is not set -# CONFIG_PATA_MPC52xx is not set -# CONFIG_PATA_MPIIX is not set -# CONFIG_PATA_OLDPIIX is not set -# CONFIG_PATA_OPTI is not set -# CONFIG_PATA_SERVERWORKS is not set - -# CONFIG_SERIAL_MPC52xx is not set -# CONFIG_MPC5200_WDT is not set -CONFIG_8xxx_WDT=m -CONFIG_GEF_WDT=m - -# CONFIG_PPC_MPC5200_BUGFIX is not set -# CONFIG_NET_VENDOR_FREESCALE is not set -#CHECK: This may later become a tristate. -CONFIG_MDIO_GPIO=m - -CONFIG_SERIAL_OF_PLATFORM=y -CONFIG_DEBUG_STACKOVERFLOW=y - -# CONFIG_EMBEDDED6xx is not set - -# CONFIG_BLK_DEV_PLATFORM is not set -# CONFIG_BLK_DEV_4DRIVES is not set -# CONFIG_BLK_DEV_ALI14XX is not set -# CONFIG_BLK_DEV_DTC2278 is not set -# CONFIG_BLK_DEV_HT6560B is not set -# CONFIG_BLK_DEV_QD65XX is not set -# CONFIG_BLK_DEV_UMC8672 is not set - -# CONFIG_VIRQ_DEBUG is not set - -CONFIG_PPC_BESTCOMM_ATA=m -CONFIG_PPC_BESTCOMM_FEC=m -CONFIG_PPC_BESTCOMM_GEN_BD=m - -CONFIG_FORCE_MAX_ZONEORDER=11 -# CONFIG_PAGE_OFFSET_BOOL is not set -# CONFIG_FB_FSL_DIU is not set -CONFIG_IRQSTACKS=y -CONFIG_VIRTUALIZATION=y - -# CONFIG_DEBUG_GPIO is not set -# CONFIG_GPIO_PCA953X is not set -# CONFIG_GPIO_PCF857X is not set -# CONFIG_HTC_EGPIO is not set - -# CONFIG_TIFM_CORE is not set - -# CONFIG_BLK_CPQ_CISS_DA is not set -# CONFIG_CISS_SCSI_TAPE is not set - -# CONFIG_I2C_NFORCE2 is not set - -# CONFIG_SND_INTEL8X0 is not set -# CONFIG_SND_INTEL8X0M is not set - -# CONFIG_MEMSTICK is not set - -# CONFIG_IPMI_HANDLER is not set - -# PPC gets sad with debug alloc (bz 448598) -# CONFIG_DEBUG_PAGEALLOC is not set - -CONFIG_CRYPTO_DEV_TALITOS=m - -# CONFIG_FSL_EMB_PERFMON is not set -# CONFIG_MPC8272_ADS is not set -# CONFIG_PQ2FADS is not set -# CONFIG_EP8248E is not set -# CONFIG_MPC830x_RDB is not set -# CONFIG_MPC831x_RDB is not set -# CONFIG_MPC832x_MDS is not set -# CONFIG_MPC832x_RDB is not set -# CONFIG_MPC834x_MDS is not set -# CONFIG_MPC834x_ITX is not set -# CONFIG_MPC836x_MDS is not set -# CONFIG_MPC836x_RDK is not set -# CONFIG_MPC837x_MDS is not set -# CONFIG_MPC837x_RDB is not set -# CONFIG_SBC834x is not set -# CONFIG_ASP834x is not set -# CONFIG_KMETER1 is not set -# CONFIG_MPC8641_HPCN is not set -# CONFIG_SBC8641D is not set -# CONFIG_MPC8610_HPCD is not set -# CONFIG_FSL_LBC is not set -# CONFIG_MTD_NAND_FSL_UPM is not set - -# CONFIG_USB_MUSB_HDRC is not set - -# busted in 2.6.27 -# drivers/mtd/maps/sbc8240.c: In function 'init_sbc8240_mtd': -# drivers/mtd/maps/sbc8240.c:172: warning: passing argument 1 of 'simple_map_init' from incompatible pointer type -# drivers/mtd/maps/sbc8240.c:177: error: 'struct mtd_info' has no member named 'module' - -CONFIG_RCU_FANOUT=32 - -CONFIG_KVM_BOOK3S_32=m - -# CONFIG_SCSI_QLA_ISCSI is not set - -CONFIG_BATTERY_PMU=m - diff --git a/config-powerpc32-smp b/config-powerpc32-smp deleted file mode 100644 index 5dbe87f..0000000 --- a/config-powerpc32-smp +++ /dev/null @@ -1,3 +0,0 @@ -# CONFIG_HOTPLUG_CPU is not set -CONFIG_NR_CPUS=4 -# CONFIG_BATTERY_PMU is not set diff --git a/filter-ppc.sh b/filter-ppc.sh deleted file mode 100644 index 8ff7a3b..0000000 --- a/filter-ppc.sh +++ /dev/null @@ -1,14 +0,0 @@ -#! /bin/bash - -# This is the ppc override file for the core/drivers package split. The -# module directories listed here and in the generic list in filter-modules.sh -# will be moved to the resulting kernel-modules package for this arch. -# Anything not listed in those files will be in the kernel-core package. -# -# Please review the default list in filter-modules.sh before making -# modifications to the overrides below. If something should be removed across -# all arches, remove it in the default instead of per-arch. - -driverdirs="atm auxdisplay bcma bluetooth fmc infiniband isdn leds media memstick message mmc mtd nfc ntb pcmcia platform power ssb staging uio uwb" - -singlemods="ntb_netdev iscsi_ibft iscsi_boot_sysfs iscsi_tcp megaraid pmcraid qla1280 9pnet_rdma svcrdma xprtrdma hid-picolcd hid-prodikeys hwa-hc hwpoison-inject" diff --git a/kernel.spec b/kernel.spec index 11352bc..d460254 100644 --- a/kernel.spec +++ b/kernel.spec @@ -84,8 +84,6 @@ Summary: The Linux kernel # # standard kernel %define with_up %{?_without_up: 0} %{?!_without_up: 1} -# kernel-smp (only valid for ppc 32-bit) -%define with_smp %{?_without_smp: 0} %{?!_without_smp: 1} # kernel PAE (only valid for i686 (PAE) and ARM (lpae)) %define with_pae %{?_without_pae: 0} %{?!_without_pae: 1} # kernel-debug @@ -109,8 +107,6 @@ Summary: The Linux kernel # # Only build the base kernel (--with baseonly): %define with_baseonly %{?_with_baseonly: 1} %{?!_with_baseonly: 0} -# Only build the smp kernel (--with smponly): -%define with_smponly %{?_with_smponly: 1} %{?!_with_smponly: 0} # Only build the pae kernel (--with paeonly): %define with_paeonly %{?_with_paeonly: 1} %{?!_with_paeonly: 0} # Only build the debug kernel (--with dbgonly): @@ -193,14 +189,6 @@ Summary: The Linux kernel
# if requested, only build base kernel %if %{with_baseonly} -%define with_smp 0 -%define with_pae 0 -%define with_debug 0 -%endif - -# if requested, only build smp kernel -%if %{with_smponly} -%define with_up 0 %define with_pae 0 %define with_debug 0 %endif @@ -208,7 +196,6 @@ Summary: The Linux kernel # if requested, only build pae kernel %if %{with_paeonly} %define with_up 0 -%define with_smp 0 %define with_debug 0 %endif
@@ -218,7 +205,6 @@ Summary: The Linux kernel %define with_up 0 %define with_pae 0 %endif -%define with_smp 0 %define with_pae 0 %define with_tools 0 %define with_perf 0 @@ -228,16 +214,11 @@ Summary: The Linux kernel
%if %{with_vdso_install} # These arches install vdso/ directories. -%define vdso_arches %{all_x86} x86_64 ppc ppc64 ppc64p7 s390 s390x aarch64 ppc64le +%define vdso_arches %{all_x86} x86_64 ppc64 ppc64p7 s390 s390x aarch64 ppc64le %endif
# Overrides for generic default options
-# only ppc needs a separate smp kernel -%ifnarch ppc -%define with_smp 0 -%endif - # don't do debug builds on anything but i686 and x86_64 %ifnarch i686 x86_64 %define with_debug 0 @@ -253,12 +234,12 @@ Summary: The Linux kernel %endif
# bootwrapper is only on ppc -%ifnarch ppc ppc64 ppc64p7 ppc64le +%ifnarch ppc64 ppc64p7 ppc64le %define with_bootwrapper 0 %endif
# sparse blows up on ppc64 and sparc64 -%ifarch ppc64 ppc ppc64p7 ppc64le +%ifarch ppc64 ppc64p7 ppc64le %define with_sparse 0 %endif
@@ -311,16 +292,6 @@ Summary: The Linux kernel %define with_tools 0 %endif
-%ifarch ppc -%define asmarch powerpc -%define hdrarch powerpc -%define all_arch_configs kernel-%{version}-ppc{-,.}*config -%define image_install_path boot -%define make_target vmlinux -%define kernel_image vmlinux -%define kernel_image_elf 1 -%endif - %ifarch %{arm} %define all_arch_configs kernel-%{version}-arm*.config %define image_install_path boot @@ -368,7 +339,6 @@ Summary: The Linux kernel
%ifarch %nobuildarches %define with_up 0 -%define with_smp 0 %define with_pae 0 %define with_debuginfo 0 %define with_perf 0 @@ -382,7 +352,7 @@ Summary: The Linux kernel %endif
# Architectures we build tools/cpupower on -%define cpupowerarchs %{ix86} x86_64 ppc ppc64 ppc64p7 %{arm} aarch64 ppc64le +%define cpupowerarchs %{ix86} x86_64 ppc64 ppc64p7 %{arm} aarch64 ppc64le
# # Packages that need to be installed before the kernel is, because the %%post @@ -400,7 +370,7 @@ Version: %{rpmversion} Release: %{pkg_release} # DO NOT CHANGE THE 'ExclusiveArch' LINE TO TEMPORARILY EXCLUDE AN ARCHITECTURE BUILD. # SET %%nobuildarches (ABOVE) INSTEAD -ExclusiveArch: %{all_x86} x86_64 ppc ppc64 ppc64p7 s390 s390x %{arm} aarch64 ppc64le +ExclusiveArch: %{all_x86} x86_64 ppc64 ppc64p7 s390 s390x %{arm} aarch64 ppc64le ExclusiveOS: Linux Requires: kernel-%{?variant:%{variant}-}core-uname-r = %{KVERREL}%{?variant} Requires: kernel-%{?variant:%{variant}-}modules-uname-r = %{KVERREL}%{?variant} @@ -452,7 +422,6 @@ Source90: filter-x86_64.sh Source91: filter-armv7hl.sh Source92: filter-i686.sh Source93: filter-aarch64.sh -Source94: filter-ppc.sh Source95: filter-ppc64.sh Source96: filter-ppc64le.sh Source97: filter-s390x.sh @@ -473,8 +442,6 @@ Source32: config-x86-32-generic Source40: config-x86_64-generic
Source50: config-powerpc-generic -Source51: config-powerpc32-generic -Source52: config-powerpc32-smp Source53: config-powerpc64 Source54: config-powerpc64p7 Source55: config-powerpc64le @@ -923,15 +890,6 @@ Provides: kernel-%{?1:%{1}-}core-uname-r = %{KVERREL}%{?1:+%{1}}\
# Now, each variant package.
-%define variant_summary The Linux kernel compiled for SMP machines -%kernel_variant_package -n SMP smp -%description smp-core -This package includes a SMP version of the Linux kernel. It is -required only on machines with two or more CPUs as well as machines with -hyperthreading technology. - -Install the kernel-smp package if your machine uses two or more CPUs. - %ifnarch armv7hl %define variant_summary The Linux kernel compiled for PAE capable machines %kernel_variant_package %{pae} @@ -995,13 +953,6 @@ exit 1 %endif %endif
-%if %{with_smponly} -%if !%{with_smp} -echo "Cannot build --with smponly, smp build is disabled" -exit 1 -%endif -%endif - %if "%{baserelease}" == "0" echo "baserelease must be greater than zero" exit 1 @@ -1588,7 +1539,7 @@ BuildKernel() { fi rm -f $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/scripts/*.o rm -f $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/scripts/*/*.o -%ifarch ppc ppc64 ppc64p7 +%ifarch ppc64 ppc64p7 cp -a --parents arch/powerpc/lib/crtsavres.[So] $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/ %endif if [ -d arch/%{asmarch}/include ]; then @@ -1773,10 +1724,6 @@ BuildKernel %make_target %kernel_image %{pae} BuildKernel %make_target %kernel_image %endif
-%if %{with_smp} -BuildKernel %make_target %kernel_image smp -%endif - %global perf_make \ make -s %{?cross_opts} %{?_smp_mflags} -C tools/perf V=1 WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_LIBNUMA=1 NO_STRLCPY=1 NO_BIONIC=1 prefix=%{_prefix} %if %{with_perf} @@ -2062,9 +2009,6 @@ fi}\ %kernel_variant_preun %kernel_variant_post -r kernel-smp
-%kernel_variant_preun smp -%kernel_variant_post -v smp - %kernel_variant_preun %{pae} %kernel_variant_post -v %{pae} -r (kernel|kernel-smp)
@@ -2217,7 +2161,6 @@ fi
%kernel_variant_files %{with_up} -%kernel_variant_files %{with_smp} smp %kernel_variant_files %{with_debug} debug %kernel_variant_files %{with_pae} %{pae} %kernel_variant_files %{with_pae_debug} %{pae}debug @@ -2236,6 +2179,9 @@ fi # ||----w | # || || %changelog +* Fri May 16 2014 Josh Boyer jwboyer@fedoraproject.org +- Remove ppc32 support + * Thu May 15 2014 Josh Boyer jwboyer@fedoraproject.org - 3.15.0-0.rc5.git2.9 - Fix build fail on s390x
On Friday, May 16, 2014, 12:22:26 PM, Josh Boyer wrote:
The powerpc secondary arch team has disabled all ppc32 builds in koji for F21 and beyond:
https://lists.fedoraproject.org/pipermail/ppc/2014-May/002801.html
There's little point in keeping support for ppc32 support in the kernel package when it will never be built. This also removes the -smp variant and with_smp* support, as that was only used on ppc32.
Josh,
In the fedora-ppc list you will also find that there are a number of us who are attempting to keep support for ppc32 active, and restore the ability to create new installations.
This may take the form of a remix - it has been suggested that we talk to Fesco, this this seems to set a precedent on how x84 32-bit might be treated in the future.
We have no intention of preventing a successful Fedora 21 release for ppc64. A number of folks on the ppc64 team agree it is a useful goal (largely those with nostalgic feelings for vintage hardware). Others are more of the "take it out behind the barn and shoot it" category.
Making it so that ppc32 does not get built by default is one thing, but removing the ability to build ppc32 at all seems excessive, and certainly premature given the current situation.
Thanks for your consideration. Al
On Fri, May 16, 2014 at 2:37 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Friday, May 16, 2014, 12:22:26 PM, Josh Boyer wrote:
The powerpc secondary arch team has disabled all ppc32 builds in koji for F21 and beyond:
https://lists.fedoraproject.org/pipermail/ppc/2014-May/002801.html
There's little point in keeping support for ppc32 support in the kernel package when it will never be built. This also removes the -smp variant and with_smp* support, as that was only used on ppc32.
Josh,
In the fedora-ppc list you will also find that there are a number of us who are attempting to keep support for ppc32 active, and restore the ability to create new installations.
Yes. I've commented on the thread.
This may take the form of a remix - it has been suggested that we talk to Fesco, this this seems to set a precedent on how x84 32-bit might be treated in the future.
I doubt that. i686 will most like go to a secondary arch status like ppc64 is today. ppc32 has been demoted even further down than secondary arch, as the secondary arch team that was working on it no longer wishes to do so.
In essence, ppc32 is now analogous to sparc and ia64 in Fedora.
We have no intention of preventing a successful Fedora 21 release for ppc64. A number of folks on the ppc64 team agree it is a useful goal (largely those with nostalgic feelings for vintage hardware). Others are more of the "take it out behind the barn and shoot it" category.
Making it so that ppc32 does not get built by default is one thing,
Actually, it's a very very big thing. Those wishing to keep it alive now need to come up with their own build hardware and build enviroment setup. This is by far the largest hurdle, and if it isn't done quickly the ppc32 secondary-secondary (thirdary?) arch will quickly fall behind and into disrepair.
As someone that actually was crazy enough to do this kind of thing when ppc/ppc64 was originally dropped, I would highly recommend you get on it immediately.
but removing the ability to build ppc32 at all seems excessive, and certainly premature given the current situation.
Which is why I sent it as a patch instead of simply committed it. Discussion is requested. At a minimum though, I really would like to drop the -smp flavor because it was of very limited use even when ppc was a primary arch and it adds the most complication to the spec.
josh
Hello Josh,
On Friday, May 16, 2014, 2:50:15 PM, you wrote:
On Fri, May 16, 2014 at 2:37 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Friday, May 16, 2014, 12:22:26 PM, Josh Boyer wrote:
The powerpc secondary arch team has disabled all ppc32 builds in koji for F21 and beyond:
https://lists.fedoraproject.org/pipermail/ppc/2014-May/002801.html
There's little point in keeping support for ppc32 support in the kernel package when it will never be built. This also removes the -smp variant and with_smp* support, as that was only used on ppc32.
Josh,
In the fedora-ppc list you will also find that there are a number of us who are attempting to keep support for ppc32 active, and restore the ability to create new installations.
Yes. I've commented on the thread.
This may take the form of a remix - it has been suggested that we talk to Fesco, this this seems to set a precedent on how x84 32-bit might be treated in the future.
I doubt that. i686 will most like go to a secondary arch status like ppc64 is today. ppc32 has been demoted even further down than secondary arch, as the secondary arch team that was working on it no longer wishes to do so.
In essence, ppc32 is now analogous to sparc and ia64 in Fedora.
I know someone who has sparc, alpha hardware. I'm not sure if they have an ia64 box taking up space in a closet somewhere.
A core advantage for ppc32 is that one can still readily get hardware for a quite reasonable price locally or on EBay.
Because of branding, I would certainly prefer that ppc32 remain under the Fedora umbrella as a seconday-secondary tertiary architecture rather than be forced to become a remix.
We have no intention of preventing a successful Fedora 21 release for ppc64. A number of folks on the ppc64 team agree it is a useful goal (largely those with nostalgic feelings for vintage hardware). Others are more of the "take it out behind the barn and shoot it" category.
Making it so that ppc32 does not get built by default is one thing,
Actually, it's a very very big thing. Those wishing to keep it alive now need to come up with their own build hardware and build enviroment setup. This is by far the largest hurdle, and if it isn't done quickly the ppc32 secondary-secondary (thirdary?) arch will quickly fall behind and into disrepair.
I hope that we can prevent things from becoming as hopeless as sparc and ia64. Being a viable separate secondary arch for older hardware is certainly a better fate than a dead tertiary arch.
Some folks have volunteered to host the builds, and provide build hardware. We'll see how that works out. If we do have to build outside the Fedora systems, there are going to be security considerations.
As someone that actually was crazy enough to do this kind of thing when ppc/ppc64 was originally dropped, I would highly recommend you get on it immediately.
Trying. I likely spent too much time gathering a representative mix of hardware. Lesson learned.
but removing the ability to build ppc32 at all seems excessive, and certainly premature given the current situation.
Which is why I sent it as a patch instead of simply committed it. Discussion is requested. At a minimum though, I really would like to drop the -smp flavor because it was of very limited use even when ppc was a primary arch and it adds the most complication to the spec.
Thanks for clarifying that.
The problem with dropping smp is that I and other have smp hardware that we would like to use. That is also likely the hardware that would best be used for builds, should "build native" and lack of a ppc32 cross compiler & binutils mean we can's use a ppc64 build host.
Al
On Fri, May 16, 2014 at 3:12 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
Hello Josh,
On Friday, May 16, 2014, 2:50:15 PM, you wrote:
On Fri, May 16, 2014 at 2:37 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Friday, May 16, 2014, 12:22:26 PM, Josh Boyer wrote:
The powerpc secondary arch team has disabled all ppc32 builds in koji for F21 and beyond:
https://lists.fedoraproject.org/pipermail/ppc/2014-May/002801.html
There's little point in keeping support for ppc32 support in the kernel package when it will never be built. This also removes the -smp variant and with_smp* support, as that was only used on ppc32.
Josh,
In the fedora-ppc list you will also find that there are a number of us who are attempting to keep support for ppc32 active, and restore the ability to create new installations.
Yes. I've commented on the thread.
This may take the form of a remix - it has been suggested that we talk to Fesco, this this seems to set a precedent on how x84 32-bit might be treated in the future.
I doubt that. i686 will most like go to a secondary arch status like ppc64 is today. ppc32 has been demoted even further down than secondary arch, as the secondary arch team that was working on it no longer wishes to do so.
In essence, ppc32 is now analogous to sparc and ia64 in Fedora.
I know someone who has sparc, alpha hardware. I'm not sure if they have an ia64 box taking up space in a closet somewhere.
Great. I know someone that has the hardware too. We still removed support for both in the kernel spec because it was entirely moribund. Hardware availability is often secondary to sustained effort from people that have that hardware. History shows that people seem less interested in keeping it running when they have to do the work or go it alone in doing the work.
A core advantage for ppc32 is that one can still readily get hardware for a quite reasonable price locally or on EBay.
Because of branding, I would certainly prefer that ppc32 remain under the Fedora umbrella as a seconday-secondary tertiary architecture rather than be forced to become a remix.
Branding?
We have no intention of preventing a successful Fedora 21 release for ppc64. A number of folks on the ppc64 team agree it is a useful goal (largely those with nostalgic feelings for vintage hardware). Others are more of the "take it out behind the barn and shoot it" category.
Making it so that ppc32 does not get built by default is one thing,
Actually, it's a very very big thing. Those wishing to keep it alive now need to come up with their own build hardware and build enviroment setup. This is by far the largest hurdle, and if it isn't done quickly the ppc32 secondary-secondary (thirdary?) arch will quickly fall behind and into disrepair.
Some folks have volunteered to host the builds, and provide build hardware. We'll see how that works out. If we do have to build outside the Fedora systems, there are going to be security considerations.
Outside build systems are probably going to be a requirement here. That is how ARM started, so it's not unreasonable. I doubt you're going to get Fedora Infrastructure to host any ppc32 hardware in the colo due to both space and configuration issues (they only take rack machines).
but removing the ability to build ppc32 at all seems excessive, and certainly premature given the current situation.
Which is why I sent it as a patch instead of simply committed it. Discussion is requested. At a minimum though, I really would like to drop the -smp flavor because it was of very limited use even when ppc was a primary arch and it adds the most complication to the spec.
Thanks for clarifying that.
The problem with dropping smp is that I and other have smp hardware that we would like to use. That is also likely the hardware that
Yes, I've seen that. I'm willing to hold off on the removal for a bit to see how quickly your effort gets off the ground. I won't wait forever though.
To be clear, whatever is built is entirely supported by the team doing the ppc32 work. Any bugs filed in Fedora bugzilla will get assigned to the contact person.
would best be used for builds, should "build native" and lack of a ppc32 cross compiler & binutils mean we can's use a ppc64 build host.
Cross-compiling is not allowed in Fedora anyway. Which is really unfortunate because it is actually a very useful thing to do in situations just like this.
josh
On Friday, May 16, 2014, 4:41:51 PM, Josh Boyer wrote:
On Fri, May 16, 2014 at 3:12 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
Because of branding, I would certainly prefer that ppc32 remain under the Fedora umbrella as a seconday-secondary tertiary architecture rather than be forced to become a remix.
Branding?
My understanding is that after a Fedora-based distribution varies too far from the standard Fedora build configuration, it becomes a remix and can no longer legally be called Fedora - they must pick a name, and modify everything with the Fedora trademark.
What we've been talking about is creating a pure Fedora ppc32 build, focussing on getting the packages on the critical path, installs and Live CD/DVD creation working again. The latter is important for getting the video back into shape.
Once the basics are running, then we have reached a point where more folks can begin to contribute and help get the remaining packages into shape, starting with what that contributor feels is important.
Al
On Friday, May 16, 2014, 4:41:51 PM, Josh Boyer wrote:
On Fri, May 16, 2014 at 3:12 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Friday, May 16, 2014, 2:50:15 PM, Josh Boyer wrote:
On Fri, May 16, 2014 at 2:37 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Friday, May 16, 2014, 12:22:26 PM, Josh Boyer wrote:
I know someone who has sparc, alpha hardware. I'm not sure if they have an ia64 box taking up space in a closet somewhere.
Great. I know someone that has the hardware too. We still removed support for both in the kernel spec because it was entirely moribund.
That is reasonable.
Hardware availability is often secondary to sustained effort from people that have that hardware. History shows that people seem less interested in keeping it running when they have to do the work or go it alone in doing the work.
Human nature. We'll hope there is a different outcome.
Making it so that ppc32 does not get built by default is one thing,
Actually, it's a very very big thing. Those wishing to keep it alive now need to come up with their own build hardware and build enviroment setup. This is by far the largest hurdle, and if it isn't done quickly the ppc32 secondary-secondary (thirdary?) arch will quickly fall behind and into disrepair.
Some folks have volunteered to host the builds, and provide build hardware. We'll see how that works out. If we do have to build outside the Fedora systems, there are going to be security considerations.
Outside build systems are probably going to be a requirement here. That is how ARM started, so it's not unreasonable. I doubt you're going to get Fedora Infrastructure to host any ppc32 hardware in the colo due to both space and configuration issues (they only take rack machines).
We need to see what can be done to make sure we can stay "Fedora" under those circumstances. Being forced to be a Fedora-like remix would be a shame if that is the only issue.
but removing the ability to build ppc32 at all seems excessive, and certainly premature given the current situation.
Which is why I sent it as a patch instead of simply committed it. Discussion is requested. At a minimum though, I really would like to drop the -smp flavor because it was of very limited use even when ppc was a primary arch and it adds the most complication to the spec.
Thanks for clarifying that.
The problem with dropping smp is that I and other have smp hardware that we would like to use. That is also likely the hardware that
Yes, I've seen that. I'm willing to hold off on the removal for a bit to see how quickly your effort gets off the ground. I won't wait forever though.
Entirely reasonable.
To be clear, whatever is built is entirely supported by the team doing the ppc32 work. Any bugs filed in Fedora bugzilla will get assigned to the contact person.
That's pretty well the way it is with ARM even now, whether they like it or not.
There is likely to be a rare occasion when ppc32 discovers an issue that also affects other builds. Reproducing on on X86, X86_64, or ppc64 should allow the problem to be addressed by the regular developers.
Worst case, providing a remote login seems to be the standard approach.
would best be used for builds, should "build native" and lack of a ppc32 cross compiler & binutils mean we can's use a ppc64 build host.
Cross-compiling is not allowed in Fedora anyway. Which is really unfortunate because it is actually a very useful thing to do in situations just like this.
That is the rule for release builds, but like ARM (and ARM64) sometimes you have to use cross-compilation during bring up.
Unlike ARM, ppc64 does support user processes running in ppc32 mode (via multi-arch). Do the current (up to today) ppc32 builds run on ppc32 hardware, or do they run on ppc64 machines via multi-arch?
If there is ppc32-only hardware, why can't we continue to use it?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 16 May 2014 18:58:14 -0400 Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Friday, May 16, 2014, 4:41:51 PM, Josh Boyer wrote:
On Fri, May 16, 2014 at 3:12 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Friday, May 16, 2014, 2:50:15 PM, Josh Boyer wrote:
On Fri, May 16, 2014 at 2:37 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Friday, May 16, 2014, 12:22:26 PM, Josh Boyer wrote:
I know someone who has sparc, alpha hardware. I'm not sure if they have an ia64 box taking up space in a closet somewhere.
Great. I know someone that has the hardware too. We still removed support for both in the kernel spec because it was entirely moribund.
That is reasonable.
Hardware availability is often secondary to sustained effort from people that have that hardware. History shows that people seem less interested in keeping it running when they have to do the work or go it alone in doing the work.
Human nature. We'll hope there is a different outcome.
Making it so that ppc32 does not get built by default is one thing,
Actually, it's a very very big thing. Those wishing to keep it alive now need to come up with their own build hardware and build enviroment setup. This is by far the largest hurdle, and if it isn't done quickly the ppc32 secondary-secondary (thirdary?) arch will quickly fall behind and into disrepair.
Some folks have volunteered to host the builds, and provide build hardware. We'll see how that works out. If we do have to build outside the Fedora systems, there are going to be security considerations.
Outside build systems are probably going to be a requirement here. That is how ARM started, so it's not unreasonable. I doubt you're going to get Fedora Infrastructure to host any ppc32 hardware in the colo due to both space and configuration issues (they only take rack machines).
We need to see what can be done to make sure we can stay "Fedora" under those circumstances. Being forced to be a Fedora-like remix would be a shame if that is the only issue.
but removing the ability to build ppc32 at all seems excessive, and certainly premature given the current situation.
Which is why I sent it as a patch instead of simply committed it. Discussion is requested. At a minimum though, I really would like to drop the -smp flavor because it was of very limited use even when ppc was a primary arch and it adds the most complication to the spec.
Thanks for clarifying that.
The problem with dropping smp is that I and other have smp hardware that we would like to use. That is also likely the hardware that
Yes, I've seen that. I'm willing to hold off on the removal for a bit to see how quickly your effort gets off the ground. I won't wait forever though.
Entirely reasonable.
To be clear, whatever is built is entirely supported by the team doing the ppc32 work. Any bugs filed in Fedora bugzilla will get assigned to the contact person.
That's pretty well the way it is with ARM even now, whether they like it or not.
There is likely to be a rare occasion when ppc32 discovers an issue that also affects other builds. Reproducing on on X86, X86_64, or ppc64 should allow the problem to be addressed by the regular developers.
Worst case, providing a remote login seems to be the standard approach.
would best be used for builds, should "build native" and lack of a ppc32 cross compiler & binutils mean we can's use a ppc64 build host.
Cross-compiling is not allowed in Fedora anyway. Which is really unfortunate because it is actually a very useful thing to do in situations just like this.
That is the rule for release builds, but like ARM (and ARM64) sometimes you have to use cross-compilation during bring up.
cross compilation is the only way to bring up a new architecture
Unlike ARM, ppc64 does support user processes running in ppc32 mode (via multi-arch). Do the current (up to today) ppc32 builds run on ppc32 hardware, or do they run on ppc64 machines via multi-arch?
If there is ppc32-only hardware, why can't we continue to use it?
The builds today happen in a 32 bit chroot on 64 bit hardware. the chroot is made from scratch every build just as all the other arches are.
Dennis
On Friday, May 16, 2014, 8:07:47 PM, Dennis Gilmore wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 16 May 2014 18:58:14 -0400 Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Friday, May 16, 2014, 4:41:51 PM, Josh Boyer wrote:
On Fri, May 16, 2014 at 3:12 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Friday, May 16, 2014, 2:50:15 PM, Josh Boyer wrote:
On Fri, May 16, 2014 at 2:37 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Friday, May 16, 2014, 12:22:26 PM, Josh Boyer wrote:
I know someone who has sparc, alpha hardware. I'm not sure if they have an ia64 box taking up space in a closet somewhere.
Great. I know someone that has the hardware too. We still removed support for both in the kernel spec because it was entirely moribund.
That is reasonable.
Hardware availability is often secondary to sustained effort from people that have that hardware. History shows that people seem less interested in keeping it running when they have to do the work or go it alone in doing the work.
Human nature. We'll hope there is a different outcome.
Making it so that ppc32 does not get built by default is one thing,
Actually, it's a very very big thing. Those wishing to keep it alive now need to come up with their own build hardware and build enviroment setup. This is by far the largest hurdle, and if it isn't done quickly the ppc32 secondary-secondary (thirdary?) arch will quickly fall behind and into disrepair.
Some folks have volunteered to host the builds, and provide build hardware. We'll see how that works out. If we do have to build outside the Fedora systems, there are going to be security considerations.
Outside build systems are probably going to be a requirement here. That is how ARM started, so it's not unreasonable. I doubt you're going to get Fedora Infrastructure to host any ppc32 hardware in the colo due to both space and configuration issues (they only take rack machines).
We need to see what can be done to make sure we can stay "Fedora" under those circumstances. Being forced to be a Fedora-like remix would be a shame if that is the only issue.
but removing the ability to build ppc32 at all seems excessive, and certainly premature given the current situation.
Which is why I sent it as a patch instead of simply committed it. Discussion is requested. At a minimum though, I really would like to drop the -smp flavor because it was of very limited use even when ppc was a primary arch and it adds the most complication to the spec.
Thanks for clarifying that.
The problem with dropping smp is that I and other have smp hardware that we would like to use. That is also likely the hardware that
Yes, I've seen that. I'm willing to hold off on the removal for a bit to see how quickly your effort gets off the ground. I won't wait forever though.
Entirely reasonable.
To be clear, whatever is built is entirely supported by the team doing the ppc32 work. Any bugs filed in Fedora bugzilla will get assigned to the contact person.
That's pretty well the way it is with ARM even now, whether they like it or not.
There is likely to be a rare occasion when ppc32 discovers an issue that also affects other builds. Reproducing on on X86, X86_64, or ppc64 should allow the problem to be addressed by the regular developers.
Worst case, providing a remote login seems to be the standard approach.
would best be used for builds, should "build native" and lack of a ppc32 cross compiler & binutils mean we can's use a ppc64 build host.
Cross-compiling is not allowed in Fedora anyway. Which is really unfortunate because it is actually a very useful thing to do in situations just like this.
That is the rule for release builds, but like ARM (and ARM64) sometimes you have to use cross-compilation during bring up.
cross compilation is the only way to bring up a new architecture
Unlike ARM, ppc64 does support user processes running in ppc32 mode (via multi-arch). Do the current (up to today) ppc32 builds run on ppc32 hardware, or do they run on ppc64 machines via multi-arch?
If there is ppc32-only hardware, why can't we continue to use it?
The builds today happen in a 32 bit chroot on 64 bit hardware. the chroot is made from scratch every build just as all the other arches are.
Dennis
That's very good news. It means physical ppc32 hosting was not used up to now on ppc32, and a resurrected ppc32 should be able to play by the same rules.
On Saturday, May 17, 2014, 4:23:27 PM, Al Dunsmuir wrote:
On Friday, May 16, 2014, 8:07:47 PM, Dennis Gilmore wrote:
Unlike ARM, ppc64 does support user processes running in ppc32 mode (via multi-arch). Do the current (up to today) ppc32 builds run on ppc32 hardware, or do they run on ppc64 machines via multi-arch?
If there is ppc32-only hardware, why can't we continue to use it?
The builds today happen in a 32 bit chroot on 64 bit hardware. the chroot is made from scratch every build just as all the other arches are.
Dennis
That's very good news. It means physical ppc32 hosting was not used up to now on ppc32, and a resurrected ppc32 should be able to play by the same rules.
I'm going to continue the discussion in the ppc list, returning to the kernel list only when something new and relevant comes up.
On Fri, May 16, 2014 at 4:41 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Fri, May 16, 2014 at 3:12 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
but removing the ability to build ppc32 at all seems excessive, and certainly premature given the current situation.
Which is why I sent it as a patch instead of simply committed it. Discussion is requested. At a minimum though, I really would like to drop the -smp flavor because it was of very limited use even when ppc was a primary arch and it adds the most complication to the spec.
Thanks for clarifying that.
The problem with dropping smp is that I and other have smp hardware that we would like to use. That is also likely the hardware that
Yes, I've seen that. I'm willing to hold off on the removal for a bit to see how quickly your effort gets off the ground. I won't wait forever though.
So it's been not quite 2 months yet and I haven't seen or heard anything about this being worked on. How is the ppc32 effort going and who is working on it?
josh
kernel@lists.fedoraproject.org
-
Al Dunsmuir -
Dennis Gilmore -
Josh Boyer