Re: Automate your Fedora package maintenance using Packit

[Laura Barcziova]

Hi Sergio,

we have a full example in our docs:
https://packit.dev/docs/fedora-releases-guide#full-example or you can check
the configuration of packages that have Packit set up, e.g.
https://src.fedoraproject.org/rpms/qownnotes/blob/rawhide/f/.packit.yaml or
https://src.fedoraproject.org/rpms/micropipenv/blob/rawhide/f/.packit.yaml
(you can find more usages from our dashboard:
https://dashboard.packit.dev/jobs/pull-from-upstreams).

You could try a similar setup and test it from a dist-git pull request as
described here: https://packit.dev/docs/fedora-releases-guide#first-setup.

If you would like to further discuss your setup or you need more help, feel
free to ask or reach out directly on #packit:fedora.im
.

Laura

On Wed, Nov 15, 2023 at 12:02 AM Sérgio Basto  wrote:

> Hi,
>
> have we an example working ?
>
>  I'd like had packit
> for https://src.fedoraproject.org/rpms/libphonenumber
>
> Upstream Release Monitoring report here:
> https://bugzilla.redhat.com/show_bug.cgi?id=2237976
>
>
> I'd like have the pull request , koji_build   and bohi update
>
>
> Thank you,
>
>
>
>
> On Fri, 2023-09-15 at 09:22 +0200, Laura Barcziova wrote:
> > If you're a Fedora package maintainer, we've got an exciting
> > automation solution for you!
> >
> > At the beginning of the year, we announced a new feature called
> > pull_from_upstream that eases the process of bringing upstream
> > releases into Fedora. This feature can be easily configured directly
> > in the dist-git repository without access to the upstream (as opposed
> > to our previously introduced automation). It is most suitable for
> > simple packages with straightforward update processes (e.g. without
> > patches, or need to build in side tags).
> >
> > Our automation works on top of the Upstream Release Monitoring [1],
> > and here's how to set it up:
> >
> >1. Enable Upstream Release Monitoring for your Fedora package: set
> > the mapping of the project in Anitya and in the left column in
> > https://src.fedoraproject.org/rpms/$YourPackage, change Monitoring
> > status to Monitoring.
> >2. Add the Packit configuration with the pull_from_upstream job to
> > your dist-git repository (see example
> > https://packit.dev/docs/configuration/downstream/pull_from_upstream#e
> > xample).
> > Once set up, here's how it works:
> >  * Upstream Release Monitoring creates a Bugzilla bug when new
> > upstream versions are detected.
> >  * As a reaction to that, Packit:
> > - automatically uploads the upstream archive to the lookaside
> > cache,
> > - creates dist-git pull request(s) at
> > https://src.fedoraproject.org/ with all the necessary changes, like
> > updates to the specfile and sources.
> > If you are interested in this, read the previously published full
> > post with the details of the setup here:
> > https://packit.dev/posts/pull-from-upstream. Since the publication of
> > this post, many users have adopted this feature and provided valuable
> > feedback, allowing us to enhance the UX. We're now excited to assist
> > you in automating the process as well!
> >
> > In addition to creating pull requests in dist-git, Packit can also
> > automate Koji builds and Bodhi updates:
> >  * https://packit.dev/docs/configuration/downstream/koji_build
> >  * https://packit.dev/docs/configuration/downstream/bodhi_update
> >
> > For complete automation documentation, don't miss our comprehensive
> > Fedora release guide at: https://packit.dev/docs/fedora-releases-
> > guide. It contains all the essential information and setup tips.
> >
> > For any questions, feel free to contact us:
> > https://packit.dev/#contact.
> >
> > Best regards,
> >
> > Packit team!
> >
> > [1] https://docs.fedoraproject.org/en-US/package-
> > maintainers/Upstream_Release_Monitoring/
> > ___
> > 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.fedoraproje
> > ct.org
> > Do not reply to spam, report it: https://pagure.io/fedora-
> > infrastructure/new_issue
>
> --
> Sérgio M. B.
> ___
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list 

Re: Automate your Fedora package maintenance using Packit

[Sérgio Basto]

Hi, 

have we an example working ? 

 I'd like had packit
for https://src.fedoraproject.org/rpms/libphonenumber 

Upstream Release Monitoring report here:
https://bugzilla.redhat.com/show_bug.cgi?id=2237976


I'd like have the pull request , koji_build   and bohi update 


Thank you,




On Fri, 2023-09-15 at 09:22 +0200, Laura Barcziova wrote:
> If you're a Fedora package maintainer, we've got an exciting
> automation solution for you!
> 
> At the beginning of the year, we announced a new feature called
> pull_from_upstream that eases the process of bringing upstream
> releases into Fedora. This feature can be easily configured directly
> in the dist-git repository without access to the upstream (as opposed
> to our previously introduced automation). It is most suitable for
> simple packages with straightforward update processes (e.g. without
> patches, or need to build in side tags).
> 
> Our automation works on top of the Upstream Release Monitoring [1],
> and here's how to set it up:
> 
>    1. Enable Upstream Release Monitoring for your Fedora package: set
> the mapping of the project in Anitya and in the left column in
> https://src.fedoraproject.org/rpms/$YourPackage, change Monitoring
> status to Monitoring.
>    2. Add the Packit configuration with the pull_from_upstream job to
> your dist-git repository (see example
> https://packit.dev/docs/configuration/downstream/pull_from_upstream#e
> xample).
> Once set up, here's how it works:
>  * Upstream Release Monitoring creates a Bugzilla bug when new
> upstream versions are detected.
>  * As a reaction to that, Packit:
> - automatically uploads the upstream archive to the lookaside
> cache,
> - creates dist-git pull request(s) at
> https://src.fedoraproject.org/ with all the necessary changes, like
> updates to the specfile and sources.
> If you are interested in this, read the previously published full
> post with the details of the setup here:
> https://packit.dev/posts/pull-from-upstream. Since the publication of
> this post, many users have adopted this feature and provided valuable
> feedback, allowing us to enhance the UX. We're now excited to assist
> you in automating the process as well! 
> 
> In addition to creating pull requests in dist-git, Packit can also
> automate Koji builds and Bodhi updates:
>  * https://packit.dev/docs/configuration/downstream/koji_build 
>  * https://packit.dev/docs/configuration/downstream/bodhi_update
> 
> For complete automation documentation, don't miss our comprehensive
> Fedora release guide at: https://packit.dev/docs/fedora-releases-
> guide. It contains all the essential information and setup tips.
> 
> For any questions, feel free to contact us:
> https://packit.dev/#contact.
> 
> Best regards,
> 
> Packit team!
> 
> [1] https://docs.fedoraproject.org/en-US/package-
> maintainers/Upstream_Release_Monitoring/
> ___
> 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.fedoraproje
> ct.org
> Do not reply to spam, report it: https://pagure.io/fedora-
> infrastructure/new_issue

-- 
Sérgio M. B.
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Frantisek Lachman]

Good point, Michael https://github.com/packit/packit/pull/2089..;)
(Will be in production next week.)

There are multiple ways to tweak the format:
* https://packit.dev/docs/configuration#copy_upstream_release_description
* https://packit.dev/docs/configuration#sync_changelog
* Or a custom `changelog-entry` action:
https://packit.dev/docs/configuration/actions#syncing-the-release

If you are not happy with any wording, suggestions and ideally pull
requests are always more than welcome!

František

On Tue, Sep 19, 2023 at 11:33 AM Michael J Gruber  
wrote:
>
> Am Di., 19. Sept. 2023 um 11:24 Uhr schrieb Frantisek Lachman
> :
> >
> > Thank you everyone for your responses!
> >
> > I have a few updates for you that made it to production this morning
> > as part of our weekly release cycle:
> >
> > * Thanks to Ankur Sinha, the pull requests created by Packit now have
> > a clear list of tasks/reminders to check in the description. (E.g.
> > https://src.fedoraproject.org/rpms/python-ogr/pull-request/479)
>
> Thanks!
>
> Maybe add: "check the autogenerated changelog" ;-)
>
> (I know 479 was not merged, but the diff looks funny.)
> Michael
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Michael J Gruber]

Am Di., 19. Sept. 2023 um 11:24 Uhr schrieb Frantisek Lachman
:
>
> Thank you everyone for your responses!
>
> I have a few updates for you that made it to production this morning
> as part of our weekly release cycle:
>
> * Thanks to Ankur Sinha, the pull requests created by Packit now have
> a clear list of tasks/reminders to check in the description. (E.g.
> https://src.fedoraproject.org/rpms/python-ogr/pull-request/479)

Thanks!

Maybe add: "check the autogenerated changelog" ;-)

(I know 479 was not merged, but the diff looks funny.)
Michael
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Frantisek Lachman]

Thank you everyone for your responses!

I have a few updates for you that made it to production this morning
as part of our weekly release cycle:

* Thanks to Ankur Sinha, the pull requests created by Packit now have
a clear list of tasks/reminders to check in the description. (E.g.
https://src.fedoraproject.org/rpms/python-ogr/pull-request/479)
* If you are not comfortable with lookaside uploads before the review,
you can newly set `upload_sources` to `false` and Packit won't do the
upload. The downside is, of course, the reduced benefit of the
automation since you need to do this yourself and the failed CI
builds. The default behaviour is preserved to not break the workflow
of the existing users but it's clearly mentioned in the onboarding
guide 
(https://packit.dev/docs/fedora-releases-guide#upload-archive-to-lookaside-cache).

František

On Fri, Sep 15, 2023 at 7:07 PM Adam Williamson
 wrote:
>
> On Fri, 2023-09-15 at 16:02 +0200, Frantisek Lachman wrote:
> > Thanks Dan and Daniel for the responses. You both are right. For our
> > defence, this is always setup by an existing Fedora user (=human).
> >
> > I can't speak of rel-eng (and honestly don't know) how problematic
> > this "physical removal" on request is.
> > We can at least promote the licence check more
> > and provide instructions on what to do if something does not fulfil the 
> > rules.
> > (E.g. as a part of the issue Ankur created and mentioned
> > (https://github.com/packit/packit/issues/2035))
> >
> > Does anyone have any realistic solution (or an improvement) to this
> > for Packit itself?
> >
> > We can also stop uploading the source to the lookaside cache (or make
> > it configurable),
> > but the benefit of such automation is significantly reduced.
>
> To be honest it seems a little unfair to 'pick on' Packit about this.
>
> practically speaking, we do not somehow enforce that every packager
> does a thorough license review of every new upstream version of
> everything they package before uploading it to the lookaside. We do not
> really have any protections against packagers running scratch builds
> with unredistributable content. Ultimately, we are trusting packagers
> to do this right.
>
> Packit is intended for folks/teams who are both upstream maintainers
> and downstream packagers. Such folks should already be aware of the
> licensing of the upstream and able to address any issues with it. They
> likely already pull new releases of their project downstream as a
> matter of course. Automating it doesn't really seem like it's exposing
> us to any radical increase in potential licensing problems.
> --
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://www.happyassassin.net
>
>
>
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Adam Williamson]

On Fri, 2023-09-15 at 16:02 +0200, Frantisek Lachman wrote:
> Thanks Dan and Daniel for the responses. You both are right. For our
> defence, this is always setup by an existing Fedora user (=human).
> 
> I can't speak of rel-eng (and honestly don't know) how problematic
> this "physical removal" on request is.
> We can at least promote the licence check more
> and provide instructions on what to do if something does not fulfil the rules.
> (E.g. as a part of the issue Ankur created and mentioned
> (https://github.com/packit/packit/issues/2035))
> 
> Does anyone have any realistic solution (or an improvement) to this
> for Packit itself?
> 
> We can also stop uploading the source to the lookaside cache (or make
> it configurable),
> but the benefit of such automation is significantly reduced.

To be honest it seems a little unfair to 'pick on' Packit about this.

practically speaking, we do not somehow enforce that every packager
does a thorough license review of every new upstream version of
everything they package before uploading it to the lookaside. We do not
really have any protections against packagers running scratch builds
with unredistributable content. Ultimately, we are trusting packagers
to do this right.

Packit is intended for folks/teams who are both upstream maintainers
and downstream packagers. Such folks should already be aware of the
licensing of the upstream and able to address any issues with it. They
likely already pull new releases of their project downstream as a
matter of course. Automating it doesn't really seem like it's exposing
us to any radical increase in potential licensing problems.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Chuck Anderson]

On Fri, Sep 15, 2023 at 02:35:36PM +0100, Daniel P. Berrangé wrote:
> IIUC strictly speaking content must be validated for license compliance
> before it is present on any Fedora infrastructure. IOW, doing scratch
> builds in either Koji or Copr is also predicated on having permissible
> content under an approved license, just as lookaside cache uploads are.

Doesn't the-new-hotness already do scratch builds in Koji in an automated
fashion with no license checking?
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Cristian Le via devel]

Agree it should be in Fedora CI. Maybe it can be added to the Zuul CI, 
or the default scratch build.


But to run Fedora CI, the source would need to be in the look-aside 
cache. I think it would be ok that if the packit run is 
pull_from_upstream that a licensecheck is run (after the spectool -g and 
before running the fedpkg new-sources) and report upstream if it fails. 
Then the packager can check it and re-run via the cli command to "sign" 
that they have verified it.


I don't think it is very necessary in the propose_downstream since the 
project hosting it and the packager maintaining it there should be 
responsible there. But if the check is not hard, might as well add it 
for sanity.


I have tried to run locally licensecheck -r, but I think the output is a 
bit too noisy for processing with so many "UNKNOWN". The 
--merge-licenses doesn't seem to help either. But it should still be 
doable to accumulate all detected licenses and continue if that is not 
different. An edge-case issue would be if upstream changes a specific 
section of the code to a specific license unknown to licensecheck, but I 
don't think the regular maintainer is diligent enough to do that 
rigorous check either.


On 2023/09/15 16:18, Frantisek Lachman wrote:

I quite like these checks but wouldn't it be better to have these as
part of Fedora CI? (Or any other CI system running on dist-git PRs?)

František

On Fri, Sep 15, 2023 at 4:13 PM Daniel P. Berrangé  wrote:

If you wanted to be especially helpful, perhaps Packit could compare
the old and new tarballs, and present the maintainer a list of newly
added files as a BZ attachment. It could also run 'licensecheck -r'
on old and new tarballs and report any notable changes. Still needs
human review, but that might help nudge the maintainer to actually
do the license review, as I bet it is often skipped on rebases.

With regards,
Daniel

___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Petr Pisar]

V Fri, Sep 15, 2023 at 03:13:22PM +0100, Daniel P. Berrangé napsal(a):
> I think it isn't too hard to make it acceptable, just stick a
> flag in the middle of your process that human has to acknowledge
> eg:
> 
>   1. Release monitoring files the new BZ ticket (it already includes
>  wording warning the maintainer to review the new release for
>  licensing changes).
> 
>  This BZ would have a flag set  'license-review=?' initially
> 
>   2. Maintainer reviews the new tarball to check the license
>  situation is all still golden.
> 
>  If OK, maintainer toggles flag to license-review=+,
>  else toggles to license-review=-
> 
>   3. Packit sees the flag approval and its magic happens to
>  upload tarball and file pull request, etc
> 
> 
I like this.

-- Petr


signature.asc
Description: PGP signature
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Miroslav Suchý]

Dne 15. 09. 23 v 13:18 Ankur Sinha napsal(a):

I guess it should be possible to make packit (or the-new-hotness?) run
licensecheck on the new sources and include that in the PR comment too,
perhaps also with a list of packages that depend on the one being
updated as an "impact check"?


It is almost impossible to do the check with old Callaway system. This is actually why I joined the group working on 
SPDX migration - I wanted automatically determine in Copr if the license is allowed. I found that it is actually easier 
and faster to migrate all the Fedora packages to SPDX and then use standard SPDX tooling rather than write NIH tool that 
would work with Callaway system.


When we finish the migration of Fedora to SPDX we plan to adapt tooling that will warn maintainer when new source has 
suspicious text that may be license that is not mention in License tag. But this circa two years ahead. If somebody 
wants to contribute let me know.


--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Frantisek Lachman]

Thanks for the info, Dan.

If this issue is not hit often,
I think it makes sense to ease the workflow for everyone
and go through this process if needed.
We can either inform people about how to do that
or do it for them.
(But sadly, we can't do the work of rel-eng.)

Otherwise, I think we can implement the config option to let the user decide.
Here's the issue I've just created for that:
https://github.com/packit/packit/issues/2082


František


On Fri, Sep 15, 2023 at 4:10 PM Dan Horák  wrote:
>
> On Fri, 15 Sep 2023 16:02:04 +0200
> Frantisek Lachman  wrote:
>
> > Thanks Dan and Daniel for the responses. You both are right. For our
> > defence, this is always setup by an existing Fedora user (=human).
> >
> > I can't speak of rel-eng (and honestly don't know) how problematic
> > this "physical removal" on request is.
>
> it's a process that at least 2 people must go thru, one opening a
> ticket, second doing the removal and closing the ticket ...
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Frantisek Lachman]

I quite like these checks but wouldn't it be better to have these as
part of Fedora CI? (Or any other CI system running on dist-git PRs?)

František

On Fri, Sep 15, 2023 at 4:13 PM Daniel P. Berrangé  wrote:
> If you wanted to be especially helpful, perhaps Packit could compare
> the old and new tarballs, and present the maintainer a list of newly
> added files as a BZ attachment. It could also run 'licensecheck -r'
> on old and new tarballs and report any notable changes. Still needs
> human review, but that might help nudge the maintainer to actually
> do the license review, as I bet it is often skipped on rebases.
>
> With regards,
> Daniel
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Daniel P . Berrangé]

On Fri, Sep 15, 2023 at 04:02:04PM +0200, Frantisek Lachman wrote:
> Thanks Dan and Daniel for the responses. You both are right. For our
> defence, this is always setup by an existing Fedora user (=human).
> 
> I can't speak of rel-eng (and honestly don't know) how problematic
> this "physical removal" on request is.
> We can at least promote the licence check more
> and provide instructions on what to do if something does not fulfil the rules.
> (E.g. as a part of the issue Ankur created and mentioned
> (https://github.com/packit/packit/issues/2035))
> 
> Does anyone have any realistic solution (or an improvement) to this
> for Packit itself?
> 
> We can also stop uploading the source to the lookaside cache (or make
> it configurable),
> but the benefit of such automation is significantly reduced.

I think it isn't too hard to make it acceptable, just stick a
flag in the middle of your process that human has to acknowledge
eg:

  1. Release monitoring files the new BZ ticket (it already includes
 wording warning the maintainer to review the new release for
 licensing changes).

 This BZ would have a flag set  'license-review=?' initially

  2. Maintainer reviews the new tarball to check the license
 situation is all still golden.

 If OK, maintainer toggles flag to license-review=+,
 else toggles to license-review=-

  3. Packit sees the flag approval and its magic happens to
 upload tarball and file pull request, etc


If you wanted to be especially helpful, perhaps Packit could compare
the old and new tarballs, and present the maintainer a list of newly
added files as a BZ attachment. It could also run 'licensecheck -r'
on old and new tarballs and report any notable changes. Still needs
human review, but that might help nudge the maintainer to actually
do the license review, as I bet it is often skipped on rebases.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Dan Horák]

On Fri, 15 Sep 2023 16:02:04 +0200
Frantisek Lachman  wrote:

> Thanks Dan and Daniel for the responses. You both are right. For our
> defence, this is always setup by an existing Fedora user (=human).
> 
> I can't speak of rel-eng (and honestly don't know) how problematic
> this "physical removal" on request is.

it's a process that at least 2 people must go thru, one opening a
ticket, second doing the removal and closing the ticket ...

> We can at least promote the licence check more
> and provide instructions on what to do if something does not fulfil the rules.
> (E.g. as a part of the issue Ankur created and mentioned
> (https://github.com/packit/packit/issues/2035))
> 
> Does anyone have any realistic solution (or an improvement) to this
> for Packit itself?
> 
> We can also stop uploading the source to the lookaside cache (or make
> it configurable),
> but the benefit of such automation is significantly reduced.

I think making it configurable could be the way, for example an upstream
project where I am the developer can have the upload enabled, because I
control my licensing situation, but it shouldn't be the default for a
"random" project.


Dan

> František
> 
> 
> On Fri, Sep 15, 2023 at 3:39 PM Dan Horák  wrote:
> >
> > On Fri, 15 Sep 2023 15:13:58 +0200
> > Frantisek Lachman  wrote:
> >
> > > Hi Petr,
> > >
> > > we would like to avoid storing the archive in the lookaside cache before
> > > approving but the problem is that the CI on the PR (mainly the scratch
> > > build) does not work without the archive being in the lookaside cache
> > > already. Once this becomes possible, we (=Packit) would be happy to do 
> > > this
> > > only when approved.
> > >
> > > But thanks to the archive hash, we don't build anything to Fedora that is
> > > not approved.
> >
> > but this is the problem, once uploaded, it can be reached and
> > downloaded, making Fedora distributing the content. It then needs
> > a rel-eng action to "physically" remove problematic source archive.
> >
> >
> > Dan
> > ___
> > 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
> > Do not reply to spam, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Frantisek Lachman]

Thanks Dan and Daniel for the responses. You both are right. For our
defence, this is always setup by an existing Fedora user (=human).

I can't speak of rel-eng (and honestly don't know) how problematic
this "physical removal" on request is.
We can at least promote the licence check more
and provide instructions on what to do if something does not fulfil the rules.
(E.g. as a part of the issue Ankur created and mentioned
(https://github.com/packit/packit/issues/2035))

Does anyone have any realistic solution (or an improvement) to this
for Packit itself?

We can also stop uploading the source to the lookaside cache (or make
it configurable),
but the benefit of such automation is significantly reduced.

František


On Fri, Sep 15, 2023 at 3:39 PM Dan Horák  wrote:
>
> On Fri, 15 Sep 2023 15:13:58 +0200
> Frantisek Lachman  wrote:
>
> > Hi Petr,
> >
> > we would like to avoid storing the archive in the lookaside cache before
> > approving but the problem is that the CI on the PR (mainly the scratch
> > build) does not work without the archive being in the lookaside cache
> > already. Once this becomes possible, we (=Packit) would be happy to do this
> > only when approved.
> >
> > But thanks to the archive hash, we don't build anything to Fedora that is
> > not approved.
>
> but this is the problem, once uploaded, it can be reached and
> downloaded, making Fedora distributing the content. It then needs
> a rel-eng action to "physically" remove problematic source archive.
>
>
> Dan
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Dan Horák]

On Fri, 15 Sep 2023 15:39:50 +0200
Frantisek Lachman  wrote:

> Thanks Vít for the link!
> 
> I am honestly not sure how CI should do this (and don't want to be the
> one who decides..;)
> 
> If CI does not need to have the source in the lookaside cache, Packit
> does not need to store anything in the lookaside cache (that's a good
> thing), but the maintainer can't be sure that the CI uses the same
> archive as Koji when building the package. (And someone needs to
> upload the archive into the lookaside archive later on.)

copr is able to download the sources using the SourceX tags before
building, if they use https. It is sufficient to have just the spec in a
git repo.


Dan

 
> František
> 
> On Fri, Sep 15, 2023 at 3:23 PM Vít Ondruch  wrote:
> >
> > I was proposing some methods how to enable download of sources for e.g. CI 
> > purposes here:
> >
> > https://pagure.io/packaging-committee/issue/1132#comment-769233
> >
> > But without too much success.
> >
> > But of course, CI could also be improved to download the required sources, 
> > if there is proper source URL.
> >
> >
> > Vít
> >
> >
> > Dne 15. 09. 23 v 15:13 Frantisek Lachman napsal(a):
> >
> > Hi Petr,
> >
> > we would like to avoid storing the archive in the lookaside cache before 
> > approving but the problem is that the CI on the PR (mainly the scratch 
> > build) does not work without the archive being in the lookaside cache 
> > already. Once this becomes possible, we (=Packit) would be happy to do this 
> > only when approved.
> >
> > But thanks to the archive hash, we don't build anything to Fedora that is 
> > not approved.
> >
> > If anyone has any better solution we're happy to improve. We also try to 
> > avoid Packit having too many permissions.
> >
> > František
> > (as a Packit PO)
> >
> > On Fri, Sep 15, 2023 at 1:25 PM Petr Pisar  wrote:
> >>
> >> V Fri, Sep 15, 2023 at 12:53:21PM +0200, Laura Barcziova napsal(a):
> >> > Yes, Fedora dist-git lookaside cache. The upstream archive is uploaded
> >> > automatically
> >>
> >> Did you know that a license review must precede uploading to Fedora 
> >> dist-git
> >> lookaside cache? The reason is once the archive is uploaded, Fedora
> >> distributes it.
> >>
> >> -- Petr
> >>
> >> ___
> >> 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
> >> Do not reply to spam, report it: 
> >> https://pagure.io/fedora-infrastructure/new_issue
> >
> >
> > ___
> > 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
> > Do not reply to spam, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
> >
> > ___
> > 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
> > Do not reply to spam, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Frantisek Lachman]

Thanks Vít for the link!

I am honestly not sure how CI should do this (and don't want to be the
one who decides..;)

If CI does not need to have the source in the lookaside cache, Packit
does not need to store anything in the lookaside cache (that's a good
thing), but the maintainer can't be sure that the CI uses the same
archive as Koji when building the package. (And someone needs to
upload the archive into the lookaside archive later on.)

František

On Fri, Sep 15, 2023 at 3:23 PM Vít Ondruch  wrote:
>
> I was proposing some methods how to enable download of sources for e.g. CI 
> purposes here:
>
> https://pagure.io/packaging-committee/issue/1132#comment-769233
>
> But without too much success.
>
> But of course, CI could also be improved to download the required sources, if 
> there is proper source URL.
>
>
> Vít
>
>
> Dne 15. 09. 23 v 15:13 Frantisek Lachman napsal(a):
>
> Hi Petr,
>
> we would like to avoid storing the archive in the lookaside cache before 
> approving but the problem is that the CI on the PR (mainly the scratch build) 
> does not work without the archive being in the lookaside cache already. Once 
> this becomes possible, we (=Packit) would be happy to do this only when 
> approved.
>
> But thanks to the archive hash, we don't build anything to Fedora that is not 
> approved.
>
> If anyone has any better solution we're happy to improve. We also try to 
> avoid Packit having too many permissions.
>
> František
> (as a Packit PO)
>
> On Fri, Sep 15, 2023 at 1:25 PM Petr Pisar  wrote:
>>
>> V Fri, Sep 15, 2023 at 12:53:21PM +0200, Laura Barcziova napsal(a):
>> > Yes, Fedora dist-git lookaside cache. The upstream archive is uploaded
>> > automatically
>>
>> Did you know that a license review must precede uploading to Fedora dist-git
>> lookaside cache? The reason is once the archive is uploaded, Fedora
>> distributes it.
>>
>> -- Petr
>>
>> ___
>> 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
>> Do not reply to spam, report it: 
>> https://pagure.io/fedora-infrastructure/new_issue
>
>
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
>
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Dan Horák]

On Fri, 15 Sep 2023 15:13:58 +0200
Frantisek Lachman  wrote:

> Hi Petr,
> 
> we would like to avoid storing the archive in the lookaside cache before
> approving but the problem is that the CI on the PR (mainly the scratch
> build) does not work without the archive being in the lookaside cache
> already. Once this becomes possible, we (=Packit) would be happy to do this
> only when approved.
> 
> But thanks to the archive hash, we don't build anything to Fedora that is
> not approved.

but this is the problem, once uploaded, it can be reached and
downloaded, making Fedora distributing the content. It then needs
a rel-eng action to "physically" remove problematic source archive.


Dan
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Daniel P . Berrangé]

On Fri, Sep 15, 2023 at 03:13:58PM +0200, Frantisek Lachman wrote:
> Hi Petr,
> 
> we would like to avoid storing the archive in the lookaside cache before
> approving but the problem is that the CI on the PR (mainly the scratch
> build) does not work without the archive being in the lookaside cache
> already. Once this becomes possible, we (=Packit) would be happy to do this
> only when approved.

IIUC strictly speaking content must be validated for license compliance
before it is present on any Fedora infrastructure. IOW, doing scratch
builds in either Koji or Copr is also predicated on having permissible
content under an approved license, just as lookaside cache uploads are.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Vít Ondruch]

I was proposing some methods how to enable download of sources for e.g. 
CI purposes here:


https://pagure.io/packaging-committee/issue/1132#comment-769233

But without too much success.

But of course, CI could also be improved to download the required 
sources, if there is proper source URL.



Vít


Dne 15. 09. 23 v 15:13 Frantisek Lachman napsal(a):

Hi Petr,

we would like to avoid storing the archive in the lookaside cache 
before approving but the problem is that the CI on the PR (mainly the 
scratch build) does not work without the archive being in the 
lookaside cache already. Once this becomes possible, we (=Packit) 
would be happy to do this only when approved.


But thanks to the archive hash, we don't build anything to Fedora that 
is not approved.


If anyone has any better solution we're happy to improve. We also try 
to avoid Packit having too many permissions.


František
(as a Packit PO)

On Fri, Sep 15, 2023 at 1:25 PM Petr Pisar  wrote:

V Fri, Sep 15, 2023 at 12:53:21PM +0200, Laura Barcziova napsal(a):
> Yes, Fedora dist-git lookaside cache. The upstream archive is
uploaded
> automatically

Did you know that a license review must precede uploading to
Fedora dist-git
lookaside cache? The reason is once the archive is uploaded, Fedora
distributes it.

-- Petr

___
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue


___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Frantisek Lachman]

And maybe one more related note to this. We've been asked multiple
times to do auto-merges as well, but that's not really what we want to
do. We do want human approval during the process. (Automation can
suggest the change and once approved take care of the builds/updates,
but a single tool should not go through the whole pipeline without any
human approval.)

František


On Fri, Sep 15, 2023 at 3:13 PM Frantisek Lachman  wrote:
>
> Hi Petr,
>
> we would like to avoid storing the archive in the lookaside cache before 
> approving but the problem is that the CI on the PR (mainly the scratch build) 
> does not work without the archive being in the lookaside cache already. Once 
> this becomes possible, we (=Packit) would be happy to do this only when 
> approved.
>
> But thanks to the archive hash, we don't build anything to Fedora that is not 
> approved.
>
> If anyone has any better solution we're happy to improve. We also try to 
> avoid Packit having too many permissions.
>
> František
> (as a Packit PO)
>
> On Fri, Sep 15, 2023 at 1:25 PM Petr Pisar  wrote:
>>
>> V Fri, Sep 15, 2023 at 12:53:21PM +0200, Laura Barcziova napsal(a):
>> > Yes, Fedora dist-git lookaside cache. The upstream archive is uploaded
>> > automatically
>>
>> Did you know that a license review must precede uploading to Fedora dist-git
>> lookaside cache? The reason is once the archive is uploaded, Fedora
>> distributes it.
>>
>> -- Petr
>>
>> ___
>> 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
>> Do not reply to spam, report it: 
>> https://pagure.io/fedora-infrastructure/new_issue
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Frantisek Lachman]

Hi Petr,

we would like to avoid storing the archive in the lookaside cache before
approving but the problem is that the CI on the PR (mainly the scratch
build) does not work without the archive being in the lookaside cache
already. Once this becomes possible, we (=Packit) would be happy to do this
only when approved.

But thanks to the archive hash, we don't build anything to Fedora that is
not approved.

If anyone has any better solution we're happy to improve. We also try to
avoid Packit having too many permissions.

František
(as a Packit PO)

On Fri, Sep 15, 2023 at 1:25 PM Petr Pisar  wrote:

> V Fri, Sep 15, 2023 at 12:53:21PM +0200, Laura Barcziova napsal(a):
> > Yes, Fedora dist-git lookaside cache. The upstream archive is uploaded
> > automatically
>
> Did you know that a license review must precede uploading to Fedora
> dist-git
> lookaside cache? The reason is once the archive is uploaded, Fedora
> distributes it.
>
> -- Petr
>
> ___
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Petr Pisar]

V Fri, Sep 15, 2023 at 12:53:21PM +0200, Laura Barcziova napsal(a):
> Yes, Fedora dist-git lookaside cache. The upstream archive is uploaded
> automatically

Did you know that a license review must precede uploading to Fedora dist-git
lookaside cache? The reason is once the archive is uploaded, Fedora
distributes it.

-- Petr



signature.asc
Description: PGP signature
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Ankur Sinha]

On Fri, Sep 15, 2023 12:53:21 +0200, Laura Barcziova wrote:
> Yes, Fedora dist-git lookaside cache. The upstream archive is uploaded
> automatically, but only a pull request is created in the particular dist-git
> repo with the change of the sources reference. Once the PRs are created, it is
> up to the maintainer to review these changes and, just after that, merge the
> changes with the updated reference to the respective branches.

See also: https://github.com/packit/packit/issues/2035

Packit is awesome, it really does help to automate lots of menial tasks,
but the risk really is that maintainers forget to do their due diligence
before merging the PRs and all that.

I guess it should be possible to make packit (or the-new-hotness?) run
licensecheck on the new sources and include that in the PR comment too,
perhaps also with a list of packages that depend on the one being
updated as an "impact check"?

See also: https://github.com/fedora-infra/the-new-hotness/issues/545

Another issue relevant to us Fedora package maintainers is this one
(already being worked on from what I see):
https://github.com/packit/packit/issues/1920

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


signature.asc
Description: PGP signature
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Laura Barcziova]

Yes, Fedora dist-git lookaside cache. The upstream archive is uploaded
automatically, but only a pull request is created in the particular
dist-git repo with the change of the *sources* reference. Once the PRs are
created, it is up to the maintainer to review these changes and, just after
that, merge the changes with the updated reference to the respective
branches.

Laura

On Fri, Sep 15, 2023 at 12:00 PM Petr Pisar  wrote:

> V Fri, Sep 15, 2023 at 09:22:46AM +0200, Laura Barcziova napsal(a):
> > Once set up, here's how it works:
> >
> >-
> >
> >Upstream Release Monitoring creates a Bugzilla bug when new upstream
> >versions are detected.
> >-
> >
> >As a reaction to that, Packit:
> >-
> >
> >   automatically uploads the upstream archive to the lookaside cache,
> >   -
> What lookaside cache? Fedora dist-git? Who does review licenses in the new
> upstream archive BEFORE uploading it?
>
> -- Petr
> ___
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automate your Fedora package maintenance using Packit

[Petr Pisar]

V Fri, Sep 15, 2023 at 09:22:46AM +0200, Laura Barcziova napsal(a):
> Once set up, here's how it works:
> 
>-
> 
>Upstream Release Monitoring creates a Bugzilla bug when new upstream
>versions are detected.
>-
> 
>As a reaction to that, Packit:
>-
> 
>   automatically uploads the upstream archive to the lookaside cache,
>   -
What lookaside cache? Fedora dist-git? Who does review licenses in the new
upstream archive BEFORE uploading it?

-- Petr


signature.asc
Description: PGP signature
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Automate your Fedora package maintenance using Packit

[Laura Barcziova]

If you're a Fedora package maintainer, we've got an exciting automation
solution for you!

At the beginning of the year, we announced a new feature called
pull_from_upstream that eases the process of bringing upstream releases
into Fedora. This feature can be easily configured directly in the dist-git
repository without access to the upstream (as opposed to our previously
introduced automation). It is most suitable for simple packages with
straightforward update processes (e.g. without patches, or need to build in
side tags).

Our automation works on top of the Upstream Release Monitoring [1], and
here's how to set it up:


   1.

   Enable Upstream Release Monitoring for your Fedora package: set the
   mapping of the project in Anitya and in the left column in
   https://src.fedoraproject.org/rpms/$YourPackage, change *Monitoring
   status* to *Monitoring*.
   2.

   Add the Packit configuration with the *pull_from_upstream* job to your
   dist-git repository (see example
   https://packit.dev/docs/configuration/downstream/pull_from_upstream#example
   ).

Once set up, here's how it works:

   -

   Upstream Release Monitoring creates a Bugzilla bug when new upstream
   versions are detected.
   -

   As a reaction to that, Packit:
   -

  automatically uploads the upstream archive to the lookaside cache,
  -

  creates dist-git pull request(s) at https://src.fedoraproject.org/
   with all the
  necessary changes, like updates to the specfile and sources.

If you are interested in this, read the previously published full post with
the details of the setup here: https://packit.dev/posts/pull-from-upstream.
Since the publication of this post, many users have adopted this feature
and provided valuable feedback, allowing us to enhance the UX. We're now
excited to assist you in automating the process as well!

In addition to creating pull requests in dist-git, Packit can also automate
Koji builds and Bodhi updates:

   -

   https://packit.dev/docs/configuration/downstream/koji_build
   -

   https://packit.dev/docs/configuration/downstream/bodhi_update


For complete automation documentation, don't miss our comprehensive Fedora
release guide at: https://packit.dev/docs/fedora-releases-guide. It
contains all the essential information and setup tips.

For any questions, feel free to contact us: https://packit.dev/#contact.

Best regards,

Packit team!

[1]
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring/
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue