= phenomenon = the ABI breakage in gcc 4.7 for c++ involves 740 packages. I am in the process of rebuilding them for F17 and once completed will rebuild them for f18 also.
= background analysis = making 740 updates is silly, but bodhi will puke on one update for all builds.
= implementation recommendation =
tag builds straight into f17.
QA has given the ack for doing the mass tagging. I wanted to get FESCo's ok before doing it
+1 from me.
Oh, and you might want to send out a brief FYI to the -devel list.
+1.
If possible we should see if we could obsolete any pending updates older than the rebuild packages? Or at least ask maintainers to drop older updates... no point in them if there's a newer build already in f17 tag, right?
+1
If we can't/won't get more automation, perhaps it would make sense to send a list of affected packages to fedora-devel to let the maintainers handle obsoleted updates themselves.
+1 I am also inclined to let the maintainers handle obsoleted updates themselves if this cannot be easily automated in bodhi. Forcibly tagging the new builds for packages which are in updates-testing due to other changes seems too risky.
As much fun as a 740-package update would be, +1. But we do need to take care about obsoleting updates.
Why is the rebuild being done in F17 first? What happened to "Rawhide first"?
I agree with Kevin, I'd prefer to see this rebuilt in Rawhide first.
Also, I'm nervous about pushing out updates to 740 packages, some of which may be sitting in updates-testing (or unpushed due to negative karma).
Is there any way we could do the rebuild only against the stable versions of packages in the repository (perhaps bumping the revisions by %{?dist}.1 instead of a full release number?
Then people can be instructed to rebuild and resubmit any testing packages they may have and we don't have to worry about accidentally pushing something into the repository that isn't ready.
It's too late now, the F17 rebuild is already complete and the Rawhide one in progress.
Late +1 for rebuild, which was already done.
ausil do you have a list of packages, which should be checked for reasons mentioned above?
Package names that were rebuilt rebuild
i will look and see if there is anything in testing for them. ill also see which FTBFS i saw there was some. I need to get the list of FTBFS for the initail mass rebuild and file bugs, there is nearly 600 packages that have not been fixed since the initall mass rebuild
The reason why i did f17 and then merged that into master is that too often i hit packages where when branched they ignore that master exists and only do work in the branched branch. so it seemed the safest bet to make sure that they did not get messed up. though this did uncover one instance where the package maintainer was builing from the master branch and not the f17 branch for f17 builds.
What is remaining to be done here?
Dennis, what is current status? Are the rebuilds in F17 already tagged into updates?
they are not yet tagged in because i dont have a good way to make sure that i only tag in the newer builds, the existing scripts do not work for this use case.
Does FESCo need to do something else with this ticket? Do you need our help or testing?
Login to comment on this ticket.