Re: Packit-as-a-Service case studies and tips
On 08. 04. 20 12:26, Ernestas Kulik wrote: As someone who also maintains the code for multiple packages, I say tough luck. The workflow for keeping upstream changes buildable (and having the ability to test the changes) and downstream package specification in sync with said changes could not be worse currently. Packit solves that for me*and* gives me the ability to pull in whatever was done downstream. As someone who routinely does mass changes across the entire collection I appreciate you pull in whatever was done downstream. But putting the spec to upstream usually means this part is neglected. In other words, if you are prepared to manually sync the 2 diverging spec files, feel free to keep your spec files on the Moon as far as I am concerned, but suggesting to other maintainers to maintain their Fedora spec files outside of Fedora without stressing this very important point is not helpful. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Packit-as-a-Service case studies and tips
On Wed, 2020-04-08 at 11:39 +0200, Miro Hrončok wrote: > On 08. 04. 20 11:33, Tomas Tomecek wrote: > > > My questions are > > > * How to manage a RPM spec file on the upstream repository, > > > synchronizing it with Fedora rawhide's one. > > Ideally, you'd maintain the spec upstream and packit will copy [1] > > it > > for you when you perform releases. > > Once again I would like to point out that the canonical source of the > spec files > in Fedora is the Fedora git. Copying upstream specfiles to Fedora via > automation > and saying "ideally, you'd maintain the spec upstream" goes against > this principle. > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenanc As someone who also maintains the code for multiple packages, I say tough luck. The workflow for keeping upstream changes buildable (and having the ability to test the changes) and downstream package specification in sync with said changes could not be worse currently. Packit solves that for me *and* gives me the ability to pull in whatever was done downstream. -- Ernestas Kulik Software Engineer Base Operating Systems - Core Services - ABRT Red Hat Czech, s.r.o. ___ 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
Re: Packit-as-a-Service case studies and tips
On 08. 04. 20 11:33, Tomas Tomecek wrote: My questions are * How to manage a RPM spec file on the upstream repository, synchronizing it with Fedora rawhide's one. Ideally, you'd maintain the spec upstream and packit will copy [1] it for you when you perform releases. Once again I would like to point out that the canonical source of the spec files in Fedora is the Fedora git. Copying upstream specfiles to Fedora via automation and saying "ideally, you'd maintain the spec upstream" goes against this principle. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenanc -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Packit-as-a-Service case studies and tips
Hi Jun, thanks for reaching out! I'd suggest CCing someone from our team in future to make sure we see your message. It's good though you started the discussion on fedora-devel. On Thu, Apr 2, 2020 at 8:54 PM Jun Aruga wrote: > > I am considering using Packit-as-a-Service [1] for an upstream > project, as the maintainer of the project suggested managing the RPM > spec file on the upstream's repository in Github. > > Could you tell me some case studies of the upstream project using > Packit-as-a-Service? > I know rebase-helper [2] is using it. There is a bunch of projects who are already integrated with packit-service at this point: * https://github.com/beaker-project/restraint/blob/master/.packit.yaml * https://github.com/abrt/faf/blob/master/.packit.yml * https://github.com/containerbuildsystem/atomic-reactor/blob/master/.packit.yaml * https://github.com/fedora-modularity/libmodulemd/blob/master/.packit.yml * https://github.com/packit-service/ogr/blob/master/.packit.yaml (and us obviously) * ... > What I want to do is > * to check the RPM spec file at the pull-request timing on GitHub, > building it on specified build targets (rawhide or fNN). This the basic use case which packit is helping to solve. > My questions are > * How to manage a RPM spec file on the upstream repository, > synchronizing it with Fedora rawhide's one. Ideally, you'd maintain the spec upstream and packit will copy [1] it for you when you perform releases. > For example, in case of rawhide, the RPM spec file's release version > is sometimes automatically updated. > I am thinking of managing the RPM spec file on the upstream without > %changelog to synchronize it easily. Packit does not sync changelogs b/w the two places because they tend to differ. As for release number -- those can get out of sync. Luckily everything is git so changes can be seen easily and reverted or updated. > * Is it possible to manage the RPM spec file including %PatchN and the > patch file on the upstream repository? It is, just include the patch file in the repo. Please let us know if you need any help with setting everything up. [1] https://packit.dev/docs/configuration/#supported-jobs (propose_downstream job) ___ 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
Re: Packit-as-a-Service case studies and tips
> * How to manage a RPM spec file on the upstream repository, synchronizing it with Fedora rawhide's one. As my first step, I am trying to use Packit, having separately managed the RPM spec file that is only used to run the %check section on the Fedora scratch build at the pull-request in the upstream. Seeing the resources such as https://github.com/packit-service/packit . -- Jun | He - His - Him ___ 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
Packit-as-a-Service case studies and tips
I am considering using Packit-as-a-Service [1] for an upstream project, as the maintainer of the project suggested managing the RPM spec file on the upstream's repository in Github. Could you tell me some case studies of the upstream project using Packit-as-a-Service? I know rebase-helper [2] is using it. What I want to do is * to check the RPM spec file at the pull-request timing on GitHub, building it on specified build targets (rawhide or fNN). My questions are * How to manage a RPM spec file on the upstream repository, synchronizing it with Fedora rawhide's one. For example, in case of rawhide, the RPM spec file's release version is sometimes automatically updated. I am thinking of managing the RPM spec file on the upstream without %changelog to synchronize it easily. * Is it possible to manage the RPM spec file including %PatchN and the patch file on the upstream repository? [1] https://packit.dev/packit-as-a-service/ [2] https://github.com/rebase-helper/rebase-helper Thanks. -- Jun | He - His - Him ___ 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
