Jonathan Wakely <jwakely@xxxxxxxxxxxxxxxxx> writes: > On 15/12/20 23:46 +0100, Miro Hrončok wrote: >>On 12/15/20 11:29 PM, Miroslav Suchý wrote: >>>I am looking for challenges for upcoming year - what I and my team should enhance. I have some ideas, but I want to hear >>>yours. >> >>Thanks for doing this! >> >>>What you - as Fedora packager - find most time consuming on packaging? >> >>Coordination and communication ;) >> >>>Where you will welcome more simplicity or automation? >> >>In testing an impact of a change. E.g. a simple "upgrade to newer >>version" change might be a problem if it breaks other packages. I >>usually spin up a copr repo and try to rebuild every dependent package > > ^ This. > > The individual steps of doing a single package are insignificant > compared to the days or WEEKS it takes for a systemwide change that > requires rebuilding hundreds of dependencies. I know not many of us > actually have this problem, but for those who do, it's very, very time > consuming. > > Since we're apparently not allowed to use a side tag to do a test > rebuild for this kind of thing, I end up doing it locally on my own > machines. Copr is another option, but I don't think it would be any > quicker or simpler. > > What I'd really like would be a "test mass rebuild" process, where a > prospective package is uploaded and everything that depends on it is > automatically rebuilt (ideally after creating the dependency graph so > each individual package doesn't get rebuilt until its dependencies are > finished building). > > Creating the dependency graph by hand is fairly tedious, but maybe I'm > missing an automated way. The point of creating that graph is to avoid > wasting time and power doing and redoing builds that will fail until > something else has been built (which is the problem with mock's > --chain command, if I understand correctly). > > Once I have that graph, I use Make to control the process, because it > handles the dependency graph, as well as parallelism, and not > rebuilding things unnecessarily. Assuming that you have all packages that you care about checked out in a directory, you can use Jens Petersen's fbrnch to build them in the correct order: https://github.com/juhp/fbrnch#parallel-building But, that only works if there are no dependency loops in your packages, which is more or less guaranteed in a non-trivial subset set of all Fedora packages. Iirc there was also the idea to leverage Zuul for doing these kinds of automated tests, but I am not sure how feasible that actually is. Even in openSUSE Tumbleweed, which is developed in OBS, automated rebuilds are disabled and only a small set of all packages is rebuild in a staging area before being other packages are merged into the distro. And that's for the simple reason, that OBS does not have enough workers to support this (and OBS has more workers than we do, while Tumbleweed has less packages than Fedora). > >>in it. However, there are time consuming challenges with this: >> >>1) False failures. Sometimes, the copr build fails for random reason >>(Koji repo is not available, etc.). I need to read the logs and figure >>it out, resubmit the build. >> >>2) Unrelated failures. Many packages FTBFS for unrelated reasons. I >>need to spin up another (control) copr and rebuild all failures there >>as well to make sure it's indeed unrelated. > > Yes, that's a real pain. Can we just add everything to Koschei instead > of having it opt-in? Yes please, Koschei should be opt-out, not opt-in.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx
