Learn more about these different git repos.
Other Git URLs
The fedora 35 schedule[1] has a mass rebuild scheduled for Jul 21 2021, We need to plan and coordinate all tasks in preparation for it.
[1] https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html
Here is a list of changes for mass rebuild:
F35 rebase to libffi 3.4 F35 Change: IBus 1.5.25 F35MingwEnvToolchainUpdate F35 change: rpm 4.17 Autoconf-2.71 F34LTO Build Improvements
See also https://pagure.io/fesco/issue/2648#comment-743962
Please also note that the mass rebuild rebuild script needs to be run with rpmdevtools 9.5 for rpmautospec support in rpmdev-bumpspec. Earlier versions will mangle .spec files that use %autorelease and %autochangelog and produce broken packages.
I talked to @petersen, we are going to not include ghc 8.10 for this mass rebuild.
Metadata Update from @mohanboddu: - Issue tagged with: high-gain, high-trouble, ops
That reminds me, there is one more thing: I think the mass rebuild script will also need small adaptations for rpmautospec. For packages that use it, there will not be any changes to files in the dist-git repo, so I think "git commit" will have to be run with "--allow-empty", otherwise git will not create a commit for the mass rebuild.
I see that the mass rebuild script uses the "fedpkg commit" wrapper for this, I don't know if that supports passing through this flag to git - otherwise fedpkg commit -s -p -m $MSG will have to be replaced with git commit -s -m $MSG --allow-empty and git push.
fedpkg commit -s -p -m $MSG
git commit -s -m $MSG --allow-empty
git push
fedpkg commit should allow passing arbitrary git options after --.
--
Thanks, @decathorpe, @churchyard I will update the mass rebuild script before running.
Just a HEADS UP but I was just starting my migration of OpenEXR from 2.5 to 3.0 which includes some significant library changes. I went ahead and killed off my side tag to wait until after the rebuild but I have already committed the changes to a couple of packages including OpenEXR so there will be some related build failures.
Depending on when the mass rebuild finishes I can clean it up no problem but I am going on vacation starting Saturday. I'll have a laptop and internet via cell phone but no guarantees how often I'll have down time to work on it. For that reason here's the affected packages with my notes:
aqsis - Move to openexr2 bcd - Moved to openexr2 blender - seems to be failing for Python related issue calligra - Moved to openexr2, FTBFS for FontConfig reasons CTL - Moved to openexr2 darktable Field3D freeimage gegl04 gimp gmic gstreamer1-plugins-bad-free hugin ImageMagick kdebase3 - Moved to openexr2, FTBFS w/ RPATH issue kdelibs - Moved to openexr2 kde-runtime - Moved to openexr2 kf5-kimageformats kio-extras krita luminance-hdr luxcorerender opencv OpenImageIO OpenSceneGraph openshadinglanguage openvdb pfstools povray prusa-slicer synfig synfigstudio vigra vips YafaRay
So here's the question, should I go ahead and commit the changes I have staged?
@hobbes1069 Mass rebuild commits to dist-git will take only a day, so maybe tomorrow you can make you changes and build them. But if you want to include OpenEXR 3 in this mass rebuild, then you have to make the changes now.
I have no packages that use rpmautospec but the first two I have looked at (GeoIP and Judy) have commit messages but no changes to the spec. The GeoIP build worked OK because there was no existing build for Fedora 35 but that's not the case for Judy, which I expect to fail with an "already built" error from koji. Or am I missing something?
Yep, it seems like the mass rebuild is treating every package as if rpmautospec is enabled.
I've pinged @humaton on IRC:
(17:10:31) jednorozec: mhroncok, going to stop it (17:13:16) jednorozec: so the problem is I have replaced fedpkg commit with git commit and there is no git add
The problem has been fixed and we started rerunning another mass rebuild.
I'm trying to fix a few builds in the f35-rebuild tag while I can. I can see that OpenEXR 3.0.5 was built, but all dependencies I'm trying to build are still pulling in 2.5.5 and I can't figure out why.
IIRC packages built in f35-rebuild are not available for other packages in that target.
I should have mentioned, I'm using fedpkg --target f35-rebuild
fedpkg --target f35-rebuild
Hey, is it possible that the script is skipping some packages? Some examples of packages that seem to have been "missed":
(c.f. discussion on the devel list)
I checked https://kojipkgs.fedoraproject.org/mass-rebuild/f35-need-rebuild.html under my username (decathorpe), and for all packages listed there for me, no mass rebuild commit / build was triggered. A lot of the other packages on this page weren't rebuilt either. Did the script really "miss" almost 2000 packages?
That doesn't matter. Both f35 and f35-rebuild use the f35-build buildroot... ie, none of the packages in f35-rebuild are in the buildroot until we tag it back.
I'm not sure what happened to skip those packages. ;( Perhaps @humaton can check the output monday morning and see what happened? We might want to do all those and/or just resubmit all failed builds?
Also, it seems the f35-rebuild signing wasn't pushed/activated, so we have to sign the builds. ;( I am running a manual signing now, not sure when it might finish. We might just merge it to f35 tag at once and then make sure that tag is signed (rawhide composes will fail until everything is signed), but at least that will land everything in the buildroot.
I have no idea. It looks like they were not processed at all. There's not even a mass rebuild commit for all my "need-rebuild" packages, so just resubmitting them won't work.
This should give a good approximation of what went wrong:
egrep -L "Fedora_35_Mass_Rebuild|\%autochangelog|\%autorelease" rpm-specs/*
This gives me 1119 packages that either
Checking some of the packages in the grep output confirms that they were indeed not touched by the mass rebuild script.
Hi, I have checked the mass rebuild logs, and there was a recurring exception in the log.
sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) FATAL: remaining connection slots are reserved for non-replication superuser connections
I can resubmit that packages manually.
That was caused by https://pagure.io/fedora-infrastructure/issue/10121
The second run is on the way, I have noticed the same exception occurring at least once. SO some additional builds will be required.
I have noticed the same exception occurring at least once
Consider letting infra know in https://pagure.io/fedora-infrastructure/issue/10121
I wonder why was it necessary to run the build with "Second attempt" in the commit message/changelog entry?
It wasn't. Hopefully, this will not cause too much of confusion.
Metadata Update from @humaton: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.