On Mon, 20 Apr 2020 at 01:33, Ondrej Nosek <onosek@xxxxxxxxxx> wrote: > > Thanks for answers, comment in the text follows. > > On Tue, Apr 14, 2020 at 12:16 PM clime <clime@xxxxxxxxxxxxxxxxx> wrote: >> >> On Tue, 14 Apr 2020 at 12:05, Vít Ondruch <vondruch@xxxxxxxxxx> wrote: >> > >> > >> > Dne 14. 04. 20 v 0:13 Ondrej Nosek napsal(a): >> > >> > TLDR: Is $SUBJ function reasonable to implement in fedpkg? >> > >> > Hi, >> > >> > some time ago, fedpkg issue tracker got a request [1] for method, that allows direct builds. That means without sending srpms via "--srpm" argument. Currently, user's changes can be built: >> > >> > fedpkg scratch-build --srpm >> > >> > This way, fedpkg sends srpm file to koji. Without "--srpm", fedpkg sends just (git) hash id to koji. But fedpkg needs modification to send a right hash id for user changes. Additionally, koji doesn't allow building hash ids from forked repos. >> > >> > >> > Even if this was possible, that would also mean that the sources have to be uploaded into look-a-side cache. Then it very much depend what is the content of the PR. If I am building Ruby nightly snapshots, I don't think it is fair to pollute look-a-side cache with them and I am afraid this is not the only case. I wish we had a way to override the look-a-side cache somehow .... >> >> If I understand correctly, this would have to be done, if sources >> changed only, right? I.e. if there is a change just in patch or a spec >> file, the sources could be fetched from the main project. > > > Yes, just sources (and eventually other binary files) are uploaded to lookaside cache. In the case of specfile and patches, there is no lookaside modification. Fork shares the same lookaside cache with the main project. Cool! > >> >> >> Should there be a possibility to upload sources for a fork that would >> then be moved to the main project when the pull request is merged? > > > That sounds complicated to me and maybe it is not worth the intended result. Or I didn't find the right (easier) approach. ... New sources (and binaries) in fork need to be saved somewhere. > - In a parallel lookaside (for forks) Yes, this is what I was thinking about. > - In git repo (omitting lookaside) > During the merge, some trigger would move the sources to the main lookaside. This creates a new file hash(es). I don't think it creates new file hashes. I mean checksums of the files should stay the same as the content stays the same, no? Maybe I am omitting something. > And it would result in another commit done by a trigger. I think it is an unwanted situation. I think an additional commit should not be needed due to above. > Some pollution of lookaside seems inevitable. But it happens even now without possibility to take uploaded file back. Yes, that's true. --- I think the solution with fork-specific sources is mainly problematic. > >> >> > >> > >> > Vít >> > >> > >> > The question to the community. Is reasonable to implement this way of building scratches? --srpm argument would still work as previously. >> > >> > There is a suggested PR for this here: [2]. It is not completed yet. >> > >> > Risks: >> > * approach could confuse users. Users are used to work with fedpkg differently. >> > * koji would have to allow these builds >> > * more code complexity; currently there is a way how to reach your result even without this function >> > >> > Thanks >> > Ondrej >> > >> > [1] https://pagure.io/fedpkg/issue/282 >> > [2] https://pagure.io/fedpkg/pull-request/390 >> > >> > _______________________________________________ >> > 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 >> > >> > _______________________________________________ >> > 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 >> _______________________________________________ >> 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 > > _______________________________________________ > 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 _______________________________________________ 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
