On Thu, 15 Jan 2026 at 11:11, Daniel P. Berrangé <[email protected]> wrote: > > On Thu, Jan 15, 2026 at 11:04:44AM +0000, Jonathan Wakely wrote: > > On Thu, 15 Jan 2026 at 09:44, Daniel P. Berrangé <[email protected]> > > wrote: > > > > > > On Sun, Jan 11, 2026 at 04:01:20PM +0000, Jonathan Wakely wrote: > > > > On Fri, 9 Jan 2026 at 20:53, sagitter--- via devel > > > > <[email protected]> wrote: > > > > > > > > > > Some of my packages need Boost; so, please, let me know when you > > > > > start the rebuilds > > > > > > > > You can check the status of your packages in the test rebuild at: > > > > https://copr.fedorainfracloud.org/coprs/ppalka/boost-1.90-2-all-arches/builds/ > > > > > > > > If the package isn't there, it doesn't depend on any boost shared > > > > libs, so we won't be rebuilding it. > > > > > > Hmm, your original mail was Jan 9th, and I fixed the linux-sgx package > > > compat with GCC 16 on Jan 7th. This copr is showing 8 attempts to rebuild > > > it using the outdated dist-git content that fails with GCC 16, and now the > > > merged side tag has created broken deps. > > > > Those are two separate things. The test builds in copr were done using > > the mass-prebuild tool. I'm not sure exactly how that works, but if > > the builds were done using content from before your fixes on Jan 7th, > > then the test builds won't have built the fixed package. > > > > But that's nothing to do with the merged side tag, which did not use > > any of the content from the copr test builds. The copr test builds are > > still in copr and only in copr and not leaving copr. The fact that > > those used old package versions doesn't affect what's in rawhide, at > > all. > > Oh I mis-understood then, as I thought that copr was supposed to give > us a heads up of problems so we could fix them before the side tag > got merged.
The copr builds were mostly just so that we (the Boost maintainers) could test building with the new boost before it got pushed to dist-git, so we'd know the scope of the changes that would be needed. If other maintainers had a look and fixed their packages, that would have been a nice bonus. It was less useful than we hoped because the GCC changes landing at the same time caused a lot of unrelated failures and obscured some Boost-related problems. And the schedule was not amenable to doing a better job. Next time I have to update Boost I won't do it around the Christmas holidays and the GCC updates, I'll schedule it for the odd-numbered Fedora releases so we do the work in the summer. > > > > Why weren't these builds done with latest rawhide ? > > > > The test builds were done with the latest rawhide *when the test > > builds started*. > > > > The side tag builds that have been merged back to rawhide were done > > with the latest rawhide too, but a much later rawhide than the test > > builds in copr, because the side tag builds were done much later. > > > > I think linux-sgx just needs to be rebuilt again with the new boost. > > That didn't happen in the side tag because linux-sgx FTBFS with the > > new boost: > > > > asio::io_service qgs_server.h:46:33: error: expected ‘)’ before ‘&’ token > > > > This is not a problem with GCC 16, so I doubt you already fixed it on Jan > > 7th. > > Indeed not, since I wasn't aware of it. I'll test this change: https://src.fedoraproject.org/fork/jwakely/rpms/linux-sgx/diff/rawhide..boost-asio-io_service > I'm wondering what the point of using the side tag was if the dependent > package maintainers aren't told of any problems before the side tag is > merged into rawhide ? I screwed up by trying to rush to do things before the mass rebuild (there's a whole existing thread about it on the devel list). -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
