I understand that builds of Ada packages have been failing on aarch64
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 aarch64.
I have no aarch64 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 an aarch64 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
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
8: Check out the master branch of gprbuild.
9: Add the tarball from step 7 as Source100 and set bootstrap_arch to
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
12: Remove Source100 and change bootstrap_arch back.
13: When the build from step 11 shows up in the buildroot, build
14: Repeat steps 8 to 13 for F24.
FYI for those that are interested.
Please coordinate with me if you feel there are patches we'll need for
a 4.5 kernel for Fedora 24 GA.
---------- Forwarded message ----------
From: Justin Forbes <jforbes(a)fedoraproject.org>
Date: Wed, Mar 16, 2016 at 4:01 PM
Subject: Kernel plans for Fedora 24
To: kernel <kernel(a)lists.fedoraproject.org>
Cc: Development discussions related to Fedora <devel(a)lists.fedoraproject.org>
With the 4.5 kernel out and the merge window for 4.6 opened up, we had
to make a decision on what the release kernel for F24 would be. The
decision has been made to ship F24 with the 4.5 kernel with 4.6
available as an update once it is ready. Timing wise, 4.6 *should*
release just before the final freeze for F24, but that is cutting it
insanely close. Should Fedora move on as scheduled, and 4.6 have some
delay due to a bug that impacts users, that would be unfortunate.
This means we have a good bit of time to make sure that everything is
working as intended with 4.5 in Fedora. It also means that any
installer critical fixes will need to be backported to 4.5.
devel mailing list
It's been a long time coming and it's finally here!
We've changed over the compose process to use pungi 4. This is now the
same process as used on primary architecture. Rather than just a
nightly repo we now do a complete compose of all supported components
on both PPC and ARM (aarch64), we're still working to get s390 over to
this new process.
At the moment on a nightly basis we're generating the Everything repo,
a Everything network installer, as well as doing Server network
installer and Server install DVD iso. Once this process settles down
I'll be adding qemu cloud images and docker base images for aarch64
and PPC, and disk images for aarch64. I'll send out details of those
components as each happens.
One of the nice side effects of this change is that the nightly
installer iso and network install images are also distributed on the
mirrors. Note the directory structure has changed a little.
So similar to the primary architectures we now have full composes
daily on both the branched Fedora 24 and 25/rawhide to make ongoing
testing easier. There will be explicit seperate Alpha/Beta/GA RC
composes and these will be coming very soon too.
This is the biggest change ever made to the secondary compose process,
and a long time in planning and implementation, so there's no doubt
some minor nits in the process. Please don't hesitate to reach out and
ask questions or raise issues either on the list or IRC.