| Message ID | 20250817205033.3845672-1-martin.jansa@gmail.com |
|---|---|
| State | Accepted |
| Delegated to: | Steve Sakoman |
| Headers | show |
| Series | [scarthgap,1/3] e2fsprogs: Fix build failure with gcc 15 | expand |
Hi Martin, Do we actually support any distribution for Scarthgap that has gcc 15 in its package feed? On 8/17/25 10:50 PM, Martin Jansa via lists.openembedded.org wrote: > From: Khem Raj <raj.khem@gmail.com> > > Backport a needed fix > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> > Signed-off-by: Martin Jansa <martin.jansa@gmail.com> > --- > ...-libext2fs-fix-std-c23-build-failure.patch | 42 +++++++++++++++++++ > .../e2fsprogs/e2fsprogs_1.47.0.bb | 1 + > 2 files changed, 43 insertions(+) > create mode 100644 meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-libext2fs-fix-std-c23-build-failure.patch > > diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-libext2fs-fix-std-c23-build-failure.patch b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-libext2fs-fix-std-c23-build-failure.patch > new file mode 100644 > index 0000000000..01ab9d5afb > --- /dev/null > +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-libext2fs-fix-std-c23-build-failure.patch > @@ -0,0 +1,42 @@ > +From 72dcef02bee9924c4d5b3dc6e7ef4d07becebcc6 Mon Sep 17 00:00:00 2001 > +From: Rudi Heitbaum <rudi@heitbaum.com> > +Date: Fri, 22 Nov 2024 12:36:32 +0000 > +Subject: [PATCH] libext2fs: fix -std=c23 build failure > + > +gcc-15 switched to -std=c23 by default: > + > + https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=55e3bd376b2214e200fa76d12b67ff259b06c212 > + > +As a result `e2fsprogs` fails the build so only typedef int bool > +for __STDC_VERSION__ <= 201710L (C17) > + > + ../../../lib/ext2fs/tdb.c:113:13: error: two or more data types in declaration specifiers > + ../../../lib/ext2fs/tdb.c:113:1: warning: useless type name in empty declaration > + 113 | typedef int bool; > + | ^~~~~~~ > + > +https://github.com/tytso/e2fsprogs/issues/202 > + > +Upstream-Status: Backport [https://github.com/tytso/e2fsprogs/commit/49fd04d77b3244c6c6990be41142168eef373aef] > +Signed-off-by: Rudi Heitbaum <rudi@heitbaum.com> > +Link: https://lore.kernel.org/r/Z0B60JhdvT9bpSQ6@6f91903e89da > +Signed-off-by: Theodore Ts'o <tytso@mit.edu> > +Signed-off-by: Khem Raj <raj.khem@gmail.com> > +--- > + lib/ext2fs/tdb.c | 2 ++ > + 1 file changed, 2 insertions(+) > + > +diff --git a/lib/ext2fs/tdb.c b/lib/ext2fs/tdb.c > +index b07b2917..98dc95d8 100644 > +--- a/lib/ext2fs/tdb.c > ++++ b/lib/ext2fs/tdb.c > +@@ -110,7 +110,9 @@ static char *rep_strdup(const char *s) > + #endif > + #endif > + > ++#if defined __STDC__ && defined __STDC_VERSION__ && __STDC_VERSION__ <= 201710L > + typedef int bool; > ++#endif > + > + #include "tdb.h" > + > diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.47.0.bb b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.47.0.bb > index 940b47c155..0288854527 100644 > --- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.47.0.bb > +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.47.0.bb > @@ -4,6 +4,7 @@ SRC_URI += "file://remove.ldconfig.call.patch \ > file://run-ptest \ > file://ptest.patch \ > file://mkdir_p.patch \ > + file://0001-libext2fs-fix-std-c23-build-failure.patch \ > " > SRC_URI:append:class-native = " \ > file://e2fsprogs-fix-missing-check-for-permission-denied.patch \ > > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#222018): https://lists.openembedded.org/g/openembedded-core/message/222018 > Mute This Topic: https://lists.openembedded.org/mt/114753788/6293953 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [quentin.schulz@cherry.de] > -=-=-=-=-=-=-=-=-=-=-=- >
On Tue, Aug 19, 2025 at 11:21 AM Quentin Schulz <quentin.schulz@cherry.de> wrote: > > Hi Martin, > > Do we actually support any distribution for Scarthgap that has gcc 15 in > its package feed? I haven't built the whole world, but these changes allowed me to build our images with gcc-15 from ubuntu-25.10 with scarthgap (and 2 more changes sent for walnascar). So even when it's not officially supported (or tested on AB), these changes are safe enough, right?
Hi Martin, On 8/19/25 11:24 AM, Martin Jansa wrote: > On Tue, Aug 19, 2025 at 11:21 AM Quentin Schulz > <quentin.schulz@cherry.de> wrote: >> >> Hi Martin, >> >> Do we actually support any distribution for Scarthgap that has gcc 15 in >> its package feed? > > I haven't built the whole world, but these changes allowed me to build > our images with gcc-15 from ubuntu-25.10 with scarthgap (and 2 more > changes sent for walnascar). > > So even when it's not officially supported (or tested on AB), these > changes are safe enough, right? My opinion is if you want to build an old branch on an unsupported distro, you maintain a fork yourself. Otherwise use containers (kas, CROPS, ...) to build old branches on unsupported distros. Master of course is a different topic, and patches to support new GCC/glibc/musl/clang/cmake/whatever on yet-unsupported distros is *very much* welcome. I'm not sure we need to add on maintainer load by patching Yocto for unsupported distros. But that's a call the maintainer(s) and or TSC to make. Meanwhile, quoting our wiki https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS#Stable/LTS_Patch_Acceptance_Policies """ Potentially Acceptable: Fixes so codebase works with newly released distros (only in the first six months after a given release series first releases) """ Considering we release twice a year, I guess the rule of thumb is: is there a more recent (tagged) release than the one you want to backport to? Yes, then backport denied. No, then backport arguable with the community. So I guess this would make backporting to Walnascar **potentially acceptable** while for Scarthgap not. We should probably add the information from the wiki (if still applicable) to the docs instead of the wiki. Cheers, Quentin
On Tue, Aug 19, 2025 at 11:57 AM Quentin Schulz <quentin.schulz@cherry.de> wrote: > > Hi Martin, > > On 8/19/25 11:24 AM, Martin Jansa wrote: > > On Tue, Aug 19, 2025 at 11:21 AM Quentin Schulz > > <quentin.schulz@cherry.de> wrote: > >> > >> Hi Martin, > >> > >> Do we actually support any distribution for Scarthgap that has gcc 15 in > >> its package feed? > > > > I haven't built the whole world, but these changes allowed me to build > > our images with gcc-15 from ubuntu-25.10 with scarthgap (and 2 more > > changes sent for walnascar). > > > > So even when it's not officially supported (or tested on AB), these > > changes are safe enough, right? > > My opinion is if you want to build an old branch on an unsupported > distro, you maintain a fork yourself. Otherwise use containers (kas, > CROPS, ...) to build old branches on unsupported distros. Master of > course is a different topic, and patches to support new > GCC/glibc/musl/clang/cmake/whatever on yet-unsupported distros is *very > much* welcome. I use containers, this one with ubuntu-25.10, I can switch to older ubuntu if needed, but it's useful to catch issues early (by someone who can also provided patches where needed, instead of random people reporting that LTS versions don't work on their new system). All of these changes are backports from master where it was already fixed by Khem or me before (with the exception of cairo where I've backported just 2 fixes from upstream instead of whole minor upgrade as the rest of the upgrade isn't needed for LTS). > I'm not sure we need to add on maintainer load by patching Yocto for > unsupported distros. But that's a call the maintainer(s) and or TSC to make. Agreed, Steve already queued the patches in scarthgap-nut, similar fixes were already merged in meta-clang and meta-tensorflow, so hopefully these small changes to keep the LTS buildable on newer OS versions don't add too much trouble for them. I am not asking anyone to regularly validate that older LTS work on newer OS then what was originally tested, but if small already tested fix is identified, sent and doesn't break anything on older supported OSes, then is it too much to ask for it being applied? Cheers,
On Tue, 2025-08-19 at 13:36 +0200, Martin Jansa wrote: > On Tue, Aug 19, 2025 at 11:57 AM Quentin Schulz > <quentin.schulz@cherry.de> wrote: > > > > Hi Martin, > > > > On 8/19/25 11:24 AM, Martin Jansa wrote: > > > On Tue, Aug 19, 2025 at 11:21 AM Quentin Schulz > > > <quentin.schulz@cherry.de> wrote: > > > > > > > > Hi Martin, > > > > > > > > Do we actually support any distribution for Scarthgap that has > > > > gcc 15 in > > > > its package feed? > > > > > > I haven't built the whole world, but these changes allowed me to > > > build > > > our images with gcc-15 from ubuntu-25.10 with scarthgap (and 2 > > > more > > > changes sent for walnascar). > > > > > > So even when it's not officially supported (or tested on AB), > > > these > > > changes are safe enough, right? > > > > My opinion is if you want to build an old branch on an unsupported > > distro, you maintain a fork yourself. Otherwise use containers > > (kas, > > CROPS, ...) to build old branches on unsupported distros. Master of > > course is a different topic, and patches to support new > > GCC/glibc/musl/clang/cmake/whatever on yet-unsupported distros is > > *very > > much* welcome. > > I use containers, this one with ubuntu-25.10, I can switch to older > ubuntu if needed, but it's useful to catch issues early (by someone > who can also provided patches where needed, instead of random people > reporting that LTS versions don't work on their new system). > > All of these changes are backports from master where it was already > fixed by Khem or me before (with the exception of cairo where I've > backported just 2 fixes from upstream instead of whole minor upgrade > as the rest of the upgrade isn't needed for LTS). > > > I'm not sure we need to add on maintainer load by patching Yocto > > for > > unsupported distros. But that's a call the maintainer(s) and or TSC > > to make. > > Agreed, Steve already queued the patches in scarthgap-nut, similar > fixes were already merged in meta-clang and meta-tensorflow, so > hopefully these small changes to keep the LTS buildable on newer OS > versions don't add too much trouble for them. > > I am not asking anyone to regularly validate that older LTS work on > newer OS then what was originally tested, but if small already tested > fix is identified, sent and doesn't break anything on older supported > OSes, then is it too much to ask for it being applied? Our policy has been to accept simple changes to keep the releases building on newer distros as long as they're not too invasive/risky. As the releases age, the barrier to entry increases. Where a distro is known to work, we also have been known to enable testing on it. It really has to be on a case by case basis though, not all distro changes are equal and we can't know in advance what they are. Cheers, Richard
On Tue, Aug 19, 2025 at 9:31 AM Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > On Tue, 2025-08-19 at 13:36 +0200, Martin Jansa wrote: > > On Tue, Aug 19, 2025 at 11:57 AM Quentin Schulz > > <quentin.schulz@cherry.de> wrote: > > > > > > Hi Martin, > > > > > > On 8/19/25 11:24 AM, Martin Jansa wrote: > > > > On Tue, Aug 19, 2025 at 11:21 AM Quentin Schulz > > > > <quentin.schulz@cherry.de> wrote: > > > > > > > > > > Hi Martin, > > > > > > > > > > Do we actually support any distribution for Scarthgap that has > > > > > gcc 15 in > > > > > its package feed? > > > > > > > > I haven't built the whole world, but these changes allowed me to > > > > build > > > > our images with gcc-15 from ubuntu-25.10 with scarthgap (and 2 > > > > more > > > > changes sent for walnascar). > > > > > > > > So even when it's not officially supported (or tested on AB), > > > > these > > > > changes are safe enough, right? > > > > > > My opinion is if you want to build an old branch on an unsupported > > > distro, you maintain a fork yourself. Otherwise use containers > > > (kas, > > > CROPS, ...) to build old branches on unsupported distros. Master of > > > course is a different topic, and patches to support new > > > GCC/glibc/musl/clang/cmake/whatever on yet-unsupported distros is > > > *very > > > much* welcome. > > > > I use containers, this one with ubuntu-25.10, I can switch to older > > ubuntu if needed, but it's useful to catch issues early (by someone > > who can also provided patches where needed, instead of random people > > reporting that LTS versions don't work on their new system). > > > > All of these changes are backports from master where it was already > > fixed by Khem or me before (with the exception of cairo where I've > > backported just 2 fixes from upstream instead of whole minor upgrade > > as the rest of the upgrade isn't needed for LTS). > > > > > I'm not sure we need to add on maintainer load by patching Yocto > > > for > > > unsupported distros. But that's a call the maintainer(s) and or TSC > > > to make. > > > > Agreed, Steve already queued the patches in scarthgap-nut, similar > > fixes were already merged in meta-clang and meta-tensorflow, so > > hopefully these small changes to keep the LTS buildable on newer OS > > versions don't add too much trouble for them. > > > > I am not asking anyone to regularly validate that older LTS work on > > newer OS then what was originally tested, but if small already tested > > fix is identified, sent and doesn't break anything on older supported > > OSes, then is it too much to ask for it being applied? > > Our policy has been to accept simple changes to keep the releases > building on newer distros as long as they're not too invasive/risky. As > the releases age, the barrier to entry increases. > > Where a distro is known to work, we also have been known to enable > testing on it. It really has to be on a case by case basis though, not > all distro changes are equal and we can't know in advance what they > are. Richard took the words right out of my mouth :-) An additional factor for supporting newer releases when feasible is that older releases on autobuilder workers are phased out over time, leaving a smaller and smaller pool available for LTS testing. Being able to add newer releases to the LTS worker pool is definitely a good thing! Steve
Thanks Richard and Steve! Crofton reported ncurses-native issue yesterday on #oe, so I've sent fix for that as well as cmake-native and git-native which were failing after that (then noticed that Rudi already reported these a month ago in Fedora 42 https://lists.yoctoproject.org/g/yocto/message/65542 ) Then I've realized that bunch of -native deps weren't rebuilt in my builds, due to sstate still being valid after updating docker image with new ubuntu-25.10 snapshot having gcc-15, so I did one more scarthgap and walnascar build without any sstate to catch them all (this time with gentoo with gcc-15 and python-14 to catch all bleeding edge cases). Now I've a bit longer set of fixes to send: a3403dabc9 (HEAD -> jansa/scarthgap, l/jansa/scarthgap, l/HEAD) yocto-uninative: Update to 4.9 for glibc 2.42 ee2ff5c8e5 yocto-uninative: Update to 4.8 for GCC 15.1 b3c18663ea pkgconfig: fix build with gcc-15 9e6c809248 unifdef: Don't use C23 constexpr keyword 390be89335 gdbm: Use C11 standard c0f2eff170 gmp: Fix build with older gcc versions 10a482993b gmp: Fix build with GCC15/C23 1cf6c77ae4 m4: Stick to C17 standard 0aaed0c782 unzip: Fix build with GCC-15 and there will be few more before the build finishes (libtirpc-native elfutils-native libgpg-error-native) 5cbb155559 lib/oe/utils: use multiprocessing from bb The last one depends on bde29045a Use a "fork" multiprocessing context for bitbake which would require minimum version bump for scarthgap (and similarly for walnascar as well). The question is, should I send them all in single batch once my local builds are finished, or just gcc-15 first and then possibly python-14/bitbake-min-version and uninative fixes later? Sorry I should have realized that I'll need to manually drop sstate to fully test this. Regards, On Tue, Aug 19, 2025 at 6:53 PM Steve Sakoman <steve@sakoman.com> wrote: > > On Tue, Aug 19, 2025 at 9:31 AM Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > > > On Tue, 2025-08-19 at 13:36 +0200, Martin Jansa wrote: > > > On Tue, Aug 19, 2025 at 11:57 AM Quentin Schulz > > > <quentin.schulz@cherry.de> wrote: > > > > > > > > Hi Martin, > > > > > > > > On 8/19/25 11:24 AM, Martin Jansa wrote: > > > > > On Tue, Aug 19, 2025 at 11:21 AM Quentin Schulz > > > > > <quentin.schulz@cherry.de> wrote: > > > > > > > > > > > > Hi Martin, > > > > > > > > > > > > Do we actually support any distribution for Scarthgap that has > > > > > > gcc 15 in > > > > > > its package feed? > > > > > > > > > > I haven't built the whole world, but these changes allowed me to > > > > > build > > > > > our images with gcc-15 from ubuntu-25.10 with scarthgap (and 2 > > > > > more > > > > > changes sent for walnascar). > > > > > > > > > > So even when it's not officially supported (or tested on AB), > > > > > these > > > > > changes are safe enough, right? > > > > > > > > My opinion is if you want to build an old branch on an unsupported > > > > distro, you maintain a fork yourself. Otherwise use containers > > > > (kas, > > > > CROPS, ...) to build old branches on unsupported distros. Master of > > > > course is a different topic, and patches to support new > > > > GCC/glibc/musl/clang/cmake/whatever on yet-unsupported distros is > > > > *very > > > > much* welcome. > > > > > > I use containers, this one with ubuntu-25.10, I can switch to older > > > ubuntu if needed, but it's useful to catch issues early (by someone > > > who can also provided patches where needed, instead of random people > > > reporting that LTS versions don't work on their new system). > > > > > > All of these changes are backports from master where it was already > > > fixed by Khem or me before (with the exception of cairo where I've > > > backported just 2 fixes from upstream instead of whole minor upgrade > > > as the rest of the upgrade isn't needed for LTS). > > > > > > > I'm not sure we need to add on maintainer load by patching Yocto > > > > for > > > > unsupported distros. But that's a call the maintainer(s) and or TSC > > > > to make. > > > > > > Agreed, Steve already queued the patches in scarthgap-nut, similar > > > fixes were already merged in meta-clang and meta-tensorflow, so > > > hopefully these small changes to keep the LTS buildable on newer OS > > > versions don't add too much trouble for them. > > > > > > I am not asking anyone to regularly validate that older LTS work on > > > newer OS then what was originally tested, but if small already tested > > > fix is identified, sent and doesn't break anything on older supported > > > OSes, then is it too much to ask for it being applied? > > > > Our policy has been to accept simple changes to keep the releases > > building on newer distros as long as they're not too invasive/risky. As > > the releases age, the barrier to entry increases. > > > > Where a distro is known to work, we also have been known to enable > > testing on it. It really has to be on a case by case basis though, not > > all distro changes are equal and we can't know in advance what they > > are. > > Richard took the words right out of my mouth :-) > > An additional factor for supporting newer releases when feasible is > that older releases on autobuilder workers are phased out over time, > leaving a smaller and smaller pool available for LTS testing. > > Being able to add newer releases to the LTS worker pool is definitely > a good thing! > > Steve
On Thu, Aug 21, 2025 at 9:37 AM Martin Jansa <martin.jansa@gmail.com> wrote: > > Thanks Richard and Steve! > > Crofton reported ncurses-native issue yesterday on #oe, so I've sent > fix for that as well as cmake-native and git-native which were failing > after that (then noticed that Rudi already reported these a month ago > in Fedora 42 https://lists.yoctoproject.org/g/yocto/message/65542 ) > > Then I've realized that bunch of -native deps weren't rebuilt in my > builds, due to sstate still being valid after updating docker image > with new ubuntu-25.10 snapshot having gcc-15, so I did one more > scarthgap and walnascar build without any sstate to catch them all > (this time with gentoo with gcc-15 and python-14 to catch all bleeding > edge cases). > > Now I've a bit longer set of fixes to send: > a3403dabc9 (HEAD -> jansa/scarthgap, l/jansa/scarthgap, l/HEAD) > yocto-uninative: Update to 4.9 for glibc 2.42 > ee2ff5c8e5 yocto-uninative: Update to 4.8 for GCC 15.1 > > b3c18663ea pkgconfig: fix build with gcc-15 > 9e6c809248 unifdef: Don't use C23 constexpr keyword > 390be89335 gdbm: Use C11 standard > c0f2eff170 gmp: Fix build with older gcc versions > 10a482993b gmp: Fix build with GCC15/C23 > 1cf6c77ae4 m4: Stick to C17 standard > 0aaed0c782 unzip: Fix build with GCC-15 > and there will be few more before the build finishes (libtirpc-native > elfutils-native libgpg-error-native) > > 5cbb155559 lib/oe/utils: use multiprocessing from bb > > The last one depends on > bde29045a Use a "fork" multiprocessing context > for bitbake which would require minimum version bump for scarthgap > (and similarly for walnascar as well). > > The question is, should I send them all in single batch once my local > builds are finished, or just gcc-15 first and then possibly > python-14/bitbake-min-version and uninative fixes later? Sorry I > should have realized that I'll need to manually drop sstate to fully > test this. Thanks for doing this! I don't have a strong preference, so whatever is convenient for you is fine by me. Steve > On Tue, Aug 19, 2025 at 6:53 PM Steve Sakoman <steve@sakoman.com> wrote: > > > > On Tue, Aug 19, 2025 at 9:31 AM Richard Purdie > > <richard.purdie@linuxfoundation.org> wrote: > > > > > > On Tue, 2025-08-19 at 13:36 +0200, Martin Jansa wrote: > > > > On Tue, Aug 19, 2025 at 11:57 AM Quentin Schulz > > > > <quentin.schulz@cherry.de> wrote: > > > > > > > > > > Hi Martin, > > > > > > > > > > On 8/19/25 11:24 AM, Martin Jansa wrote: > > > > > > On Tue, Aug 19, 2025 at 11:21 AM Quentin Schulz > > > > > > <quentin.schulz@cherry.de> wrote: > > > > > > > > > > > > > > Hi Martin, > > > > > > > > > > > > > > Do we actually support any distribution for Scarthgap that has > > > > > > > gcc 15 in > > > > > > > its package feed? > > > > > > > > > > > > I haven't built the whole world, but these changes allowed me to > > > > > > build > > > > > > our images with gcc-15 from ubuntu-25.10 with scarthgap (and 2 > > > > > > more > > > > > > changes sent for walnascar). > > > > > > > > > > > > So even when it's not officially supported (or tested on AB), > > > > > > these > > > > > > changes are safe enough, right? > > > > > > > > > > My opinion is if you want to build an old branch on an unsupported > > > > > distro, you maintain a fork yourself. Otherwise use containers > > > > > (kas, > > > > > CROPS, ...) to build old branches on unsupported distros. Master of > > > > > course is a different topic, and patches to support new > > > > > GCC/glibc/musl/clang/cmake/whatever on yet-unsupported distros is > > > > > *very > > > > > much* welcome. > > > > > > > > I use containers, this one with ubuntu-25.10, I can switch to older > > > > ubuntu if needed, but it's useful to catch issues early (by someone > > > > who can also provided patches where needed, instead of random people > > > > reporting that LTS versions don't work on their new system). > > > > > > > > All of these changes are backports from master where it was already > > > > fixed by Khem or me before (with the exception of cairo where I've > > > > backported just 2 fixes from upstream instead of whole minor upgrade > > > > as the rest of the upgrade isn't needed for LTS). > > > > > > > > > I'm not sure we need to add on maintainer load by patching Yocto > > > > > for > > > > > unsupported distros. But that's a call the maintainer(s) and or TSC > > > > > to make. > > > > > > > > Agreed, Steve already queued the patches in scarthgap-nut, similar > > > > fixes were already merged in meta-clang and meta-tensorflow, so > > > > hopefully these small changes to keep the LTS buildable on newer OS > > > > versions don't add too much trouble for them. > > > > > > > > I am not asking anyone to regularly validate that older LTS work on > > > > newer OS then what was originally tested, but if small already tested > > > > fix is identified, sent and doesn't break anything on older supported > > > > OSes, then is it too much to ask for it being applied? > > > > > > Our policy has been to accept simple changes to keep the releases > > > building on newer distros as long as they're not too invasive/risky. As > > > the releases age, the barrier to entry increases. > > > > > > Where a distro is known to work, we also have been known to enable > > > testing on it. It really has to be on a case by case basis though, not > > > all distro changes are equal and we can't know in advance what they > > > are. > > > > Richard took the words right out of my mouth :-) > > > > An additional factor for supporting newer releases when feasible is > > that older releases on autobuilder workers are phased out over time, > > leaving a smaller and smaller pool available for LTS testing. > > > > Being able to add newer releases to the LTS worker pool is definitely > > a good thing! > > > > Steve
diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-libext2fs-fix-std-c23-build-failure.patch b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-libext2fs-fix-std-c23-build-failure.patch new file mode 100644 index 0000000000..01ab9d5afb --- /dev/null +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-libext2fs-fix-std-c23-build-failure.patch @@ -0,0 +1,42 @@ +From 72dcef02bee9924c4d5b3dc6e7ef4d07becebcc6 Mon Sep 17 00:00:00 2001 +From: Rudi Heitbaum <rudi@heitbaum.com> +Date: Fri, 22 Nov 2024 12:36:32 +0000 +Subject: [PATCH] libext2fs: fix -std=c23 build failure + +gcc-15 switched to -std=c23 by default: + + https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=55e3bd376b2214e200fa76d12b67ff259b06c212 + +As a result `e2fsprogs` fails the build so only typedef int bool +for __STDC_VERSION__ <= 201710L (C17) + + ../../../lib/ext2fs/tdb.c:113:13: error: two or more data types in declaration specifiers + ../../../lib/ext2fs/tdb.c:113:1: warning: useless type name in empty declaration + 113 | typedef int bool; + | ^~~~~~~ + +https://github.com/tytso/e2fsprogs/issues/202 + +Upstream-Status: Backport [https://github.com/tytso/e2fsprogs/commit/49fd04d77b3244c6c6990be41142168eef373aef] +Signed-off-by: Rudi Heitbaum <rudi@heitbaum.com> +Link: https://lore.kernel.org/r/Z0B60JhdvT9bpSQ6@6f91903e89da +Signed-off-by: Theodore Ts'o <tytso@mit.edu> +Signed-off-by: Khem Raj <raj.khem@gmail.com> +--- + lib/ext2fs/tdb.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/lib/ext2fs/tdb.c b/lib/ext2fs/tdb.c +index b07b2917..98dc95d8 100644 +--- a/lib/ext2fs/tdb.c ++++ b/lib/ext2fs/tdb.c +@@ -110,7 +110,9 @@ static char *rep_strdup(const char *s) + #endif + #endif + ++#if defined __STDC__ && defined __STDC_VERSION__ && __STDC_VERSION__ <= 201710L + typedef int bool; ++#endif + + #include "tdb.h" + diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.47.0.bb b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.47.0.bb index 940b47c155..0288854527 100644 --- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.47.0.bb +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.47.0.bb @@ -4,6 +4,7 @@ SRC_URI += "file://remove.ldconfig.call.patch \ file://run-ptest \ file://ptest.patch \ file://mkdir_p.patch \ + file://0001-libext2fs-fix-std-c23-build-failure.patch \ " SRC_URI:append:class-native = " \ file://e2fsprogs-fix-missing-check-for-permission-denied.patch \