Hello!
I understand that builds of Ada packages have been failing on ppc64 since before the F23 release.
GPRbuild 2015 introduced some dependency loops that Koji can't handle. This was worked around with some trickery, but apparently the secondary architectures were left behind. We now have a better solution that should allow future upgrades to go smoothly, and I'd like to see if we can get GPRbuild back on track on ppc64.
I have no ppc64 hardware myself, and I'm not sure how to access the build systems that secondary architectures use, but I hope we can work together to restore GPRbuild and the packages that depend on it.
It should be possible to use the working GPRbuild in older releases to re-bootstrap GPRbuild for Rawhide and F24. The following is how it would be done on a primary architecture. The procedure may need to be adapted if things work differently for secondary architectures.
1: Take a ppc64 host running F22 or F23 and install gprbuild and gcc-gnat the usual way. You will get a dynamically linked GPRbuild 2014 that pulls in XMLada and libgnat.
2: Uninstall xmlada-devel if it is installed.
3: Copy the latest xmlada and gprbuild source packages from Rawhide or F24 to the F22 or F23 host.
4: Build xmlada with RPMbuild.
5: Use rpm --install --excludedocs to install the resulting xmlada-2015, xmlada-devel-2015 and xmlada-static-2015 packages. Do not upgrade the base package, but keep xmlada-2013 installed alongside xmlada-2015. (--excludedocs works around file conflicts.)
6: Build gprbuild with RPMbuild. This will produce a statically linked GPRbuild 2015.
7: Unpack the resulting gprbuild package and repackage the file tree in a tarball. (/usr/share/doc can be omitted but all the rest of /usr is needed.)
8: Check out the master branch of gprbuild.
9: Add the tarball from step 7 as Source100 and set bootstrap_arch to "ppc64".
10: Build gprbuild in Koji. This step gets the statically linked executables into Koji.
11: When the build from step 10 shows up in the buildroot, build xmlada in Koji.
12: Remove Source100 and change bootstrap_arch back.
13: When the build from step 11 shows up in the buildroot, build gprbuild again.
14: Repeat steps 8 to 13 for F24.
Björn Persson
Hi,
I understand that builds of Ada packages have been failing on ppc64 since before the F23 release.
GPRbuild 2015 introduced some dependency loops that Koji can't handle. This was worked around with some trickery, but apparently the secondary architectures were left behind. We now have a better solution that should allow future upgrades to go smoothly, and I'd like to see if we can get GPRbuild back on track on ppc64.
I have no ppc64 hardware myself, and I'm not sure how to access the build systems that secondary architectures use, but I hope we can work together to restore GPRbuild and the packages that depend on it.
It should be possible to use the working GPRbuild in older releases to re-bootstrap GPRbuild for Rawhide and F24. The following is how it would be done on a primary architecture. The procedure may need to be adapted if things work differently for secondary architectures.
1: Take a ppc64 host running F22 or F23 and install gprbuild and gcc-gnat the usual way. You will get a dynamically linked GPRbuild 2014 that pulls in XMLada and libgnat.
We also have ppc64le now, I actually bootsrapped GNAT for it earlier in the week. How do we build for that when there is no previous builds of gprbuild, xmlada etc?
2: Uninstall xmlada-devel if it is installed.
3: Copy the latest xmlada and gprbuild source packages from Rawhide or F24 to the F22 or F23 host.
4: Build xmlada with RPMbuild.
5: Use rpm --install --excludedocs to install the resulting xmlada-2015, xmlada-devel-2015 and xmlada-static-2015 packages. Do not upgrade the base package, but keep xmlada-2013 installed alongside xmlada-2015. (--excludedocs works around file conflicts.)
6: Build gprbuild with RPMbuild. This will produce a statically linked GPRbuild 2015.
7: Unpack the resulting gprbuild package and repackage the file tree in a tarball. (/usr/share/doc can be omitted but all the rest of /usr is needed.)
8: Check out the master branch of gprbuild.
9: Add the tarball from step 7 as Source100 and set bootstrap_arch to "ppc64".
10: Build gprbuild in Koji. This step gets the statically linked executables into Koji.
11: When the build from step 10 shows up in the buildroot, build xmlada in Koji.
12: Remove Source100 and change bootstrap_arch back.
13: When the build from step 11 shows up in the buildroot, build gprbuild again.
14: Repeat steps 8 to 13 for F24.
Björn Persson
ppc mailing list ppc@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/ppc@lists.fedoraproject.org
Peter Robinson wrote:
We also have ppc64le now, I actually bootsrapped GNAT for it earlier in the week. How do we build for that when there is no previous builds of gprbuild, xmlada etc?
I suppose you could cross-compile GPRbuild to get the initial executables. You will need a cross-compiled XMLada to link to of course. I have no experience with cross-compilation myself.
For the time being, it should also be possible to start with older releases of GPRbuild and XMLada, that are built with Gnatmake, and then build the latest GPRbuild with those.
Björn Persson
On Sat, 19 Mar 2016 21:26:17 +0100 Björn Persson Bjorn@xn--rombobjrn-67a.se wrote:
Peter Robinson wrote:
We also have ppc64le now, I actually bootsrapped GNAT for it earlier in the week. How do we build for that when there is no previous builds of gprbuild, xmlada etc?
I suppose you could cross-compile GPRbuild to get the initial executables. You will need a cross-compiled XMLada to link to of course. I have no experience with cross-compilation myself.
For the time being, it should also be possible to start with older releases of GPRbuild and XMLada, that are built with Gnatmake, and then build the latest GPRbuild with those.
we have gnat for s390x already for few weeks, so would be useful to do all new bootstrapping in one step
Dan
Dan Horák wrote:
we have gnat for s390x already for few weeks, so would be useful to do all new bootstrapping in one step
It would certainly be possible to add several bootstrap tarballs to the source package at once, and add some more ifarch selections to choose which of them to unpack.
If I had such a source package, is there a way I could trigger Koji builds for the secondary architectures, other than building in the primary Koji and waiting for all the Koji-shadows to catch up? Because I sometimes get email notifying me that some package has been built on some secondary architecture a long time after I built it in the primary Koji, so I get the impression that it can sometimes take a long time for secondary architectures to catch up. I would rather not leave the Git repository in the bootstrapping state for too long, so how could I tell the secondary Kojis to build the package immediately?
Is there a way I could do scratch builds for secondary architectures to check that things work before I commit to Git?
Björn Persson
Is there a way I could do scratch builds for secondary architectures to check that things work before I commit to Git?
Yes, it is possible to do scratch builds for secondary architectures. Commands used are: s390-koji [1] - To build for s390 and s390x ppc-koji [2] - To build for ppc64 and ppc64le arm-koji [3] - To build for aarch64
Complete syntax to initiate build is similar to how we do for primary architectures build. For example, to build package srpm1 for ppc64 and ppc64le for Fedora rawhide, run: $ ppc-koji build --scratch rawhide srpm1
[1] http://s390.koji.fedoraproject.org/ [2] ppc.koji.fedoraproject.org/ [3] http://arm.koji.fedoraproject.org/koji
Sinny Kumari wrote:
Is there a way I could do scratch builds for secondary architectures to check that things work before I commit to Git?
Yes, it is possible to do scratch builds for secondary architectures. Commands used are: s390-koji [1] - To build for s390 and s390x ppc-koji [2] - To build for ppc64 and ppc64le arm-koji [3] - To build for aarch64
Complete syntax to initiate build is similar to how we do for primary architectures build. For example, to build package srpm1 for ppc64 and ppc64le for Fedora rawhide, run: $ ppc-koji build --scratch rawhide srpm1
Thanks. Those were the commands I hadn't found. And now I think I've even managed to figure out how to compose the magic Git URL to do a real build.
Björn Persson
Status update:
Lacking actual hardware I tried to re-bootstrap GPRbuild by doing Koji builds of selected package versions in a specific order. That failed when it turned out that GPRbuild failed to recognize GCC as a suitable compiler.
After lots of trouble and setbacks I finally managed to get a ppc64 emulator installed and working just about well enough that I could build with RPMbuild and troubleshoot GPRbuild. I now have GPRbuild 2015 built for ppc64, and it seems to be able to rebuild itself.
I had no success with any other emulators, but now I have a good idea of how to get GPRbuild to find the compiler on other architectures, so I'm going to try bootstrapping through Koji again.
If I don't run into any more problems, then up-to-date packages may start to appear soonish.
Björn Persson
-
Björn Persson -
Dan Horák -
Peter Robinson -
Sinny Kumari