On Thu, Dec 17, 2020 at 10:14 AM Vít Ondruch <vondr...@redhat.com> wrote: > > > Dne 16. 12. 20 v 21:56 Neal Gompa napsal(a): > > On Wed, Dec 16, 2020 at 3:34 PM Kevin Fenzi <ke...@scrye.com> wrote: > >> On Wed, Dec 16, 2020 at 07:15:21PM +0000, Jonathan Wakely wrote: > >>> 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. > >> You actually can use a side tag, but it's not very streamlined. > >> 1. make side-tag > >> 2. push your changes to a whatever branch on the package that you are > >> changing. > >> 3. build package from that branch into the sidetag > >> 4. scratch build all the dependent packages in the sidetag and they will > >> use the changed package. Get them all working. > >> 5. merge your branch back on the package, bump release again > >> 5. actually bump and officially rebuild all the packages in the side tag > >> 6. merge sidetag > >> 7. ask releng to delete the branch you made (or not if you don't care) > >> > >> But I agree thats not great. ;( > >> > >>> 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. > >> Yeah, all this ^ > >> > > So I've written tools for doing this, and Igor has written tools for > > doing this, but it seems like people think that this is "impossible" > > and so the effort goes nowhere despite several PoCs. > > > > If we're interested in this again for real this time, I could try to > > dig out my old code for it, but we might be better off just pulling > > out Koschei's code and turning it into something that Koji's > > chain-build command and Mock's --chain option use to sort through > > package sets and build them correctly. > > > >>>> 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? > >> Thats worth considering in the new year. I would like that. :) > >> > > I would appreciate if Koschei kept more results. It is almost unuseful > these days if one does not have time to check the issue right after it > appears :(
I think this is caused by koji garbage collection? I assume the retention time it's set very short for scratch builds, which makes koschei less useful, but keeps storage use in check ... Fabio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
