| Age | Commit message (Collapse) | Author |
|---|
|
Done via:
```
git grep -l virtual/zlib$ | xargs sed -i -e 's@virtual/zlib$@&:=@'
```
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
Update done using:
```
git grep -l sys-libs/zlib dev-* | xargs sed -i -e s@sys-libs/zlib@virtual/zlib@g
git diff --name-only | xargs copybump
git diff --name-only | xargs grep -l PYTHON_COMPAT | xargs gpy-impl -@dead
pkgcheck scan --commits -c SourcingCheck,VisibilityCheck --exit error
```
Followed by manual revert in dev-python/zlib-ng where it accidentally
caught sys-libs/zlib-ng dependencies.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
Reported by phaebz.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Result of running the command:
grep --include="*.ebuild" -r . -e 'KEYWORDS=.*[" ]sparc' -l | xargs ekeyword ~sparc
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
Result of running the command:
grep --include="*.ebuild" -r . -e 'KEYWORDS=.*[" ]hppa' -l | xargs ekeyword ~hppa
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
Same chroot as before but tree state at 67eeb6e0867dd39abfd50edefd68d20919bba7e6.
Of course, couldn't use crossdev, so rebuilt natively in the chroot w/
FEATURES="buildpkg". They are newer versions of each slot because it
necessarily upgraded them to rebuild to get the binpkgs, though.
This just leaves x86 which has a similar problem (perhaps I should've
chosen a nomultilib stage3 to begin with).
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Same as fd80b52f6eb59b31526f4e75e834240e60408f0a. No real point
in having it in ~arch temporarily either.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Same as fd80b52f6eb59b31526f4e75e834240e60408f0a.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
It's prebuilt so can't be rebuilt against new subslots, of course.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
No ~loong as GCC 12 didn't support it. Adding older branches to facilitate
GCC testing. I originally wasn't going to bother but I'd like to bisect
an issue on ARM, so...
Built with ::gentoo at 6895c729372e48a5f596abd65cfeb26c178c5b17, same
stage3 as before for earlier binaries (stage3-amd64-hardened-systemd-20241214T201851Z).
The only quirk is, for `build-ada-bootsraps`, crossdev's behaviour with
--gcc to specify certain versions may use unkeyworded GCC in a particular
slot (not checked), but easy to reproduce still with the right ::gentoo commit.
See https://github.com/thesamesam/sam-gentoo-scripts/blob/2c192ac1461144fb2a2ab83014ad13794e4efc3d/niche/build-ada-bootstraps.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Bug: https://bugs.gentoo.org/938150
Bug: https://bugs.gentoo.org/940601
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Passes gcc:14 bootstrap albeit plain `emerge` of sys-devel/gcc:14
with USE=ada failed with circular dep (not trying to satisfy the
BDEPEND with dev-lang/ada-bootstrap at all before bailing). Direct
`ebuild` invocation worked.
Bug: https://bugs.gentoo.org/946645
Signed-off-by: WANG Xuerui <xen0n@gentoo.org>
|
|
Same as 8e2955e0eb4d9e00f39f41e4801893429c0ba6e7 but tree state at:
```
Timestamp of repository gentoo: Wed, 01 Jan 2025 19:18:22 +0000
Head commit of repository gentoo: 7221b3f8c7af080380122dadb60808c0a00d1b07
```
but I haven't done a world upgrade or anything like that from the stage3
as it was.
Closes: https://bugs.gentoo.org/946650
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Same environment as described in 8e2955e0eb4d9e00f39f41e4801893429c0ba6e7.
Bug: https://bugs.gentoo.org/946647
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Native bootstrap of sys-devel/gcc-14.2.1_p20241221 succeeded.
Bug: https://bugs.gentoo.org/946647
Signed-off-by: Sam James <sam@gentoo.org>
|
|
This is still using the stage3 from before (stage3-amd64-hardened-systemd-20241214T201851Z)
although with tree state this time at:
```
Timestamp of repository gentoo: Tue, 31 Dec 2024 14:03:40 +0000
Head commit of repository gentoo: db8e97771bd345dc8a801b7a056f86b4ddb43953
```
I didn't use `crossdev -S` and sed out ~hppa in make.conf this time accidentally
because of a script change I forgot to make, but I don't think it matters
as latest glibc + gcc are already stable fortunately.
Interestingly, when I tried this last (HPPA was the first arch I tried
when manually doing the ada-bootstrap work for non-amd64), it failed
w/ gen_il-main in finalization, but this time, it seems to have at least
got further...
There were some HPPA fixes Dave committed on the 14 branch
between 14.2.1_p20241116 (previous attempt) and 14.2.1_p20241221 (this one),
so that must be it, or it's that I'd made some error before as the eclass
changes and script didn't exist at that point and I was trying stuff adhoc.
Closes: https://bugs.gentoo.org/946647
Signed-off-by: Sam James <sam@gentoo.org>
|
|
For HPPA, the version is going to be newer and it's easier to do this
than hardcode another value.
Bug: https://bugs.gentoo.org/946647
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Bug: https://bugs.gentoo.org/946644
Signed-off-by: Jakov Smolić <jsmolic@gentoo.org>
|
|
Same details as cae8f6ff8f9a857ba3a07371d6b2d5d8996afb5f although I built
it at the same time as amd64 (see a73baf031bc6e4b613ae181491fedfa3e8437232).
This one was a bit delayed as wasn't included in the first batch because
they're pure ~arch (TODO: find a way to handle that more nicely in the
script to use stable for stable arches, and not otherwise; could grep
arches.desc?)
We have alpha, hppa, mips, m68k, and x86 left. m68k wasn't done yet
because its current GCC is 13 still b/c of a bootstrap failure.
Bug: https://bugs.gentoo.org/940472
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Bug: https://bugs.gentoo.org/940472
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Same details as in cae8f6ff8f9a857ba3a07371d6b2d5d8996afb5f for how it
was built, but with tree state on 17th November 2024 and not built w/
crossdev.
Bug: https://bugs.gentoo.org/940472
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Bug: https://bugs.gentoo.org/940472
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Bug: https://bugs.gentoo.org/940472
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Bug: https://bugs.gentoo.org/940472
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Otherwise, we might have ${A} containing more than one and then we unpack
the last one listed (which isn't necessarily right at all) and also fail
w/ wrong number of args to dosym.
Bug: https://bugs.gentoo.org/940472
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
This adds bootstrap tarballs for GNAT for the following platforms:
* aarch64-unknown-linux-gnu
* armv6j-softfp-linux-gnueabi
* armv6j-unknown-linux-gnueabihf
* armv7a-softfp-linux-gnueabi
* armv7a-unknown-linux-gnueabihf
* powerpc-unknown-linux-gnu
* powerpc64-unknown-linux-gnu
* powerpc64le-unknown-linux-gnu
* sparc64-unknown-linux-gnu
More are planned (like HPPA, but I had an issue there when using the
built tarball; I don't think the tarball was to blame, rather some
deeper issue needing investigation) but this feels like a decent set
to start with.
We should also of course build a fresh one for amd64 and also x86.
They were built using a script [0] using stage3-amd64-hardened-systemd-20241214T201851Z.tar.xz
with ::gentoo state around 16th November 2024 (I say "around" as I synced
in-between to get an eclass fix).
NOTE: I've only added ~arm64 for now as I've tested the binary there
to bootstrap GNAT natively. I'll add other keywords once tested.
[0] https://github.com/thesamesam/sam-gentoo-scripts/blob/91558fb51c56a661d6f374507888ff67725ca660/build-ada-bootstraps
Bug: https://bugs.gentoo.org/940472
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Michael Mair-Keimberger <mmk@levelnine.at>
Signed-off-by: Conrad Kostecki <conikost@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
I can't reproduce the failure reported but let's try this.
Closes: https://bugs.gentoo.org/940599
Signed-off-by: Sam James <sam@gentoo.org>
|
|
I copied the wrong one out of chroot :(
Closes: https://bugs.gentoo.org/940598
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Like we do for the JIT build in toolchain.eclass.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Closes: https://bugs.gentoo.org/940584
Signed-off-by: Sam James <sam@gentoo.org>
|
|
... to find the bundled gnatmake and friends, as the build system
doesn't consistently respect the env var.
Closes: https://bugs.gentoo.org/940582
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Closes: https://bugs.gentoo.org/940575
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Needed for the logic in toolchain.eclass to match what we do for
sys-devel/gcc.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Split dev-lang/gnat-gpl into dev-lang/ada-bootstrap. This ebuild
was initially a clone of dev-lang/gnat-gpl-2021-r5 then had some
cleanups done, toolchain.eclass use removed, and simplified what it
configures/builds/installs.
As I mentioned in 799693623d76c89e8b04d2434d0dfece44bb49f9, there were
two jobs left -- this fixes the first one: splitting dev-lang/gnat-gpl
into its own package which doesn't collide with sys-devel/gcc:10 and
also does the least possible work, not with lots of USE, etc.)
Some inspiration taken from sys-devel/bpf-toolchain. Considered
using the *-toolchain name again but given the purpose of this is *not*
just to avoid crossdev use but instead to bootstrap from a binary for Ada,
it didn't feel appropriate.
(Planned to do this anyway but the issue mentioned in
9732ef3475830dbe289fc80358613e90b612563c pushed me to get on with it now.)
Later versions of ada-bootstrap will be our own binaries for both
newer GCC as a base (although this is mostly a nice-to-have and to keep
things building rather than it being essential, AFAIK) as well as more
importantly musl and other arch support.
For that future work, see https://bugs.gentoo.org/940471#c1 for a
suggestion from Luke A. Guest. That will be tracked in bug #940472.
Bug: https://bugs.gentoo.org/547358
Bug: https://bugs.gentoo.org/919667
Bug: https://bugs.gentoo.org/940472
Closes: https://bugs.gentoo.org/940471
Signed-off-by: Sam James <sam@gentoo.org>
|
