Packit: Request onboarding of your package now

[Frantisek Lachman]

Hello!

In Packit, we believe that our Fedora automation is simple to set up,
but there are still many people who could benefit from it and are too
busy to onboard or just not sure if this is the right thing for their
package.

If you are one of those, the Packit team offers to prepare a
configuration for you.

And how to do it? Just fill out the following form:
https://github.com/packit/packit-service/issues/new?assignees==onboarding==onboarding.yml=Onboard+%5Bmy+package%5D

No GitHub account? No problem.
Give us the list of packages using #packit:fedora.im channel on
Matrix/Element or he...@packit.dev email.

Curious about what you can expect from Packit?
When there is a new upstream version, Packit opens a dist-git pull
request with the specfile changes.
Once you review the changes and merge the pull request,
Packit automatically triggers a Koji build and if it succeeds, Packit
creates a Bodhi update.
Want to know more about it? Check our onboarding guide:
https://packit.dev/docs/fedora-releases-guide/dist-git-onboarding

If you think a video call would be better to discuss your use case,
set up a meeting with me:
https://calendar.app.google/Hvvehu7VPMnAtBRc9

On behalf of the Packit team,
František

https://packit.dev
#packit:fedora.im (Element / Matrix)
he...@packit.dev
@pac...@fosstodon.org (Mastodon)
--
___
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

[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

[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

[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

[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

[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: Add a push update mechanism for https://release-monitoring.org/

[Frantisek Lachman]

Hello,

as Fabio has pointed out, you can use Packit to get your releases to
Fedora via pull-requests. Packit supports both push and newly also
pull workflow. (So you don't need to have access to the upstream
repository because it gets the info about the new version from Release
Monitoring.)

Thanks to it being pull-request-based, there is a Fedora CI involved
and you, as a maintainer, can see the build/test results and decide if
this should go to Fedora or not. Plus, an automatic Koji build and
Bodhi update is possible as well.

It's easy to set up. Here is the documentation for the Fedora automation:
https://packit.dev/docs/fedora-releases-guide#pull-from-upstream-job

And don't be afraid to ask. We, as a Packit team, are happy to help.

František
Packit Product Owner..;)

#packit:fedora.im (Element / Matrix)
#packit:libera.chat (IRC)
he...@packit.dev
@pac...@fosstodon.org (Mastodon)


On Mon, Aug 28, 2023 at 3:01 PM Sérgio Basto  wrote:
>
> On Mon, 2023-08-28 at 13:52 +0100, Sérgio Basto wrote:
> > On Mon, 2023-08-28 at 03:28 +, Ryan Bach via devel wrote:
> > > Faster updates are always as plus.
> > >
> > > Should this be under infrastructure list?
> > >
> > > Thoughts?
> > >
> >
> > if you got a scratch build completed in a bugzilla for example :
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=2231971
> >
> > you may use my helper script update_from_bugzilla.sh
> >
> > `fedpkg clone package-foo; cd package-foo ;
> > ../update_from_bugzilla.sh`
>
> forgot to add bugzilla number, so should be
>
> `fedpkg clone package-foo; cd package-foo ; ../update_from_bugzilla.sh
> 2231971`
>
> >
> > > Thanks in advance for all the work done to make this distro great.
> > > ___
> > > 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
> >
> > --
> > 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
>
> --
> 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 -- 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: Packit automates Koji Builds and Bodhi updates

[Frantisek Lachman]

On Fri, May 6, 2022 at 4:12 PM Miro Hrončok  wrote:
>
> That is the case for any rebuilds that happen in side tags. Most recently e.g.
> the boost rebuilds. Sometimes, maintainers do that for their own packages as
> well, but provenpackagers do that at larger scale. For Python packages, 
> that'll
> be Python rebuilds, but for other packages it might be any other targeted 
> rebuild.
>
> > I am thinking about multiple options here:
> >
> > 1) configurable allow-list / block list for committers (for the user and/or 
> > for
> > the whole service)
> > * For our projects, we would allow just the `packit` user that we use for
> > submitting the dist-git pull requests.
> > * We could probably react to just `packit` commits for all the users but I
> > don't like this all-or-nothing approach. (That people are required to use 
> > all
> > the Packit's features or none.)
>
> So when the maintainer merges a packit PR, it would trigger the build but not
> otherwise?

It can be done like this. Either as a default for the service or be
able to configure it to work like this.

> Wouldn't it be more transparent if the maintainer types a packit command to 
> the
> PR to merge+build+bodhi it when the CI passes? I even think I could use this
> (if it does not require a config config file in upstream). The command could
> even allow passing some options in the future (for setting unusual karma
> limits, etc.)

* We don't require upstream config at all for downstream jobs. (We
load the config from the respective dist-git commit.
* I am not sure if this should be the only way how to start the builds
but doable from our side.

> > We can probably think about this more, but the second option looks the best 
> > for
> > me so far. Automation is not reduced and work for proven packagers is
> > untouched. What do you think? Would this work for you? Or, do you have any
> > better idea/solution?
>
> Correct me if I am wrong, but it seems to me that this feature was built with
> limited knowledge of how *other people* use dist-git. In my view, this cannot
> be fully automated for pushes. IMHO the action *must* be triggered by the
> maintainer unless everybody is fully aware that pushes may trigger builds
> depending on some externalities, which is unlikely to happen.

We know that there are a lot of approaches around so we have chosen
the following way:
1) Require explicit opt-in in the config in dist-git.
2) Implement the basic version.
3) Gather some feedback and improve/extend. (We are here.)
4) if needed/wanted, we can provide another way of turning this on.

With the first point (explicit opt-in), people can decide if the
current state works for them or not. There are already people happy
with the basic version and since we have all the
plumbing/messaging/... already done, we can now easily make it more
complex.

> Here is a list of mentioned solutions sorted from the less-fragile to the most
> (IMHO).
>
>   1. Automation only happens when maintainer explicitly starts it
>   2. Automation only happens when a packit PR was merged*
>   3. Automation only happens for non-provenpackagers
>   4. Automation happens on every push (current way)
>
> * this could be documented in the PR initial comment

Thanks for the points, I've created an upstream issue on our issue
tracker for that: https://github.com/packit/packit-service/issues/1490

František
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packit automates Koji Builds and Bodhi updates

[Frantisek Lachman]

Yes, sure. Thanks for the example.

František

On Fri, May 6, 2022 at 2:21 PM Miro Hrončok  wrote:

> On 06. 05. 22 11:06, Frantisek Lachman wrote:
> > You can also check the activities of the packit FAS user in Koji
> > (https://koji.fedoraproject.org/koji/userinfo?userID=4641
> > <https://koji.fedoraproject.org/koji/userinfo?userID=4641>) or Bodhi (
> > https://bodhi.fedoraproject.org/users/packit
> > <https://bodhi.fedoraproject.org/users/packit>).
>
> Could you also please fill in https://fedoraproject.org/wiki/User:Packit
> with
> some emergency contact information? See for example
> https://fedoraproject.org/wiki/User:Rhcontainerbot
>
> --
> 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packit automates Koji Builds and Bodhi updates

[Frantisek Lachman]

Hi Miro,

that's a really valid point that we should somehow resolve. Is this always
the case with the mass rebuilds that they should be left unbuilt or just
with your Python rebuilds?

I am thinking about multiple options here:

1) configurable allow-list / block list for committers (for the user and/or
for the whole service)
* For our projects, we would allow just the `packit` user that we use for
submitting the dist-git pull requests.
* We could probably react to just `packit` commits for all the users but I
don't like this all-or-nothing approach. (That people are required to use
all the Packit's features or none.)

2) check the committer for not being a proven packager (Packit is not a
proven packager and we don't want to change that. We would like to have as
few permissions as possible.)
* I don't see any technical problem with the implementation here and
personally see this as a possible solution.

3) use a commit message to skip/trigger the build
* We can't inform everyone about this feature so skipping the build by
commit command is probably not a good idea.
* And forcing the commit structure to trigger the build makes it hard to
use.

We can probably think about this more, but the second option looks the best
for me so far. Automation is not reduced and work for proven packagers is
untouched. What do you think? Would this work for you? Or, do you have any
better idea/solution?

Thanks for bringing this up!
František


On Fri, May 6, 2022 at 2:19 PM Miro Hrončok  wrote:

> On 06. 05. 22 11:06, Frantisek Lachman wrote:
> > Hello all,
> >
> > You might have heard some rumours that the Packit team is working on
> automation
> > for downstream activities you need to do when working on a new release
> of a
> > package to Fedora. And the rumours are true – I am really pleased to
> announce
> > that Packit now covers the whole workflow from upstream development to
> Bodhi
> > update. We try to reduce the human interaction with the system to places
> where
> > it’s needed and wanted and do all the mundane work and busy waiting for
> you.
> >
> >
> > If you want to take a look at how it works, here is a blog post showing
> this on
> > one of our packages: https://packit.dev/posts/downstream-automation
> > <https://packit.dev/posts/downstream-automation>
> >
> >
> > We have used the automation ourselves for a couple of weeks for our
> packages[0]
> > and already got bored of the releases. It’s too simple.
> >
> > And if you haven’t heard about Packit at all, check our web page:
> > https://packit.dev <https://packit.dev>
> >
> >
> > We know that people can have different needs, so let us know what you
> think
> > about it. And if you hit any issues or have any suggestions, get in
> touch with
> > us – ideally, in #packit:fedora.im <http://fedora.im> on Fedora Matrix
> or in
> > form of an upstream issue created here:
> > https://github.com/packit/packit-service/issues/new
>
> Hey František.
>
> I read that "If Packit sees a new commit in the configured dist-git
> branch, it
> submits a new build in Koji like maintainers usually do."
>
> Does that mean that if a provenpackager (e.g. me) commits to
> rpms/python-ogr in
> order to rebuild the package in a side tag (e.g. f37-python for Python
> 3.11
> rebuild), packit will build it in the regular target, preventing the side
> tag
> build from happening (the same NVR cannot be built multiple times in Koji)?
>
> --
> 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Packit automates Koji Builds and Bodhi updates

[Frantisek Lachman]

Hello all,

You might have heard some rumours that the Packit team is working on
automation for downstream activities you need to do when working on a new
release of a package to Fedora. And the rumours are true – I am really
pleased to announce that Packit now covers the whole workflow from upstream
development to Bodhi update. We try to reduce the human interaction with
the system to places where it’s needed and wanted and do all the mundane
work and busy waiting for you.

If you want to take a look at how it works, here is a blog post showing
this on one of our packages: https://packit.dev/posts/downstream-automation


We have used the automation ourselves for a couple of weeks for our
packages[0] and already got bored of the releases. It’s too simple.

And if you haven’t heard about Packit at all, check our web page:
https://packit.dev

We know that people can have different needs, so let us know what you think
about it. And if you hit any issues or have any suggestions, get in touch
with us – ideally, in #packit:fedora.im on Fedora Matrix or in form of an
upstream issue created here:
https://github.com/packit/packit-service/issues/new

On behalf of the Packit team,
František

[0]: As an example, take a look at  `packit`
 or `python-ogr`
 package. You can also
check the activities of the packit FAS user in Koji (
https://koji.fedoraproject.org/koji/userinfo?userID=4641) or Bodhi (
https://bodhi.fedoraproject.org/users/packit).
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Bodhi 6.0: What's new

[Frantisek Lachman]

Thank you for your quick answer Aurélien!

I hope this workflow can work for us.

Maybe a few related questions (sorry if it is documented somewhere, any
link is welcome):
* What is the expiration period? Or, can we set the expiration date
ourselves?
* Can we use multiple tokens in parallel to ease the transition before the
expiration? Or, in other words, is the token revoked once we generate a new
one? If not, can we revoke it?

Thanks!
František

On Wed, Apr 6, 2022 at 2:29 PM Aurelien Bompard  wrote:

> Hey Frantisek!
>
> Excellent questions!
>
> > * Our users can use Packit via CLI and use their identity for Bodhi
> connections. With this, it's not nice, but doable to open a web-browser.
> (Not sure how this works in the containerised use-cases.)
>
> The Bodhi CLI will display a URL that you'll have to open in your web
> browser, and wait for input. After logging in, Ipsilon will give you a
> token that you need to copy/paste in the Bodhi CLI.
>
> > * Is there some way to get/generate some token that can be used instead
> of doing this browser workflow?
>
> Yes, you can do the browser workflow on any host and then copy over
> the ~/.config/bodhi/client.json file on the service's worker(s).
>
> > * Do I get it right from what you wrote about `save_override` that we
> can generate the session token elsewhere and reuse it in the service? Do
> you have some details on how this works so we can start working on the move?
>
> That's not what save_override() does, it's just an API endpoint to
> edit buildroot overrides in Bodhi.
>
> > * For other Fedora systems, we use Kerberos authentication, are there
> some plans to add it?
>
> Nope, there's no plan for that at the moment.
>
> Does this answer your questions?
>
> Aurélien
>
>
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Bodhi 6.0: What's new

[Frantisek Lachman]

Hi Aurélien!

thanks for the hard work on the new Bodhi release!

I have a question on the non-interactive way of Bodhi authentication. I
understand that supporting OpenID is hard, but are there some other options
to support this workflow in the future?

A little bit of context:
* We, as a Packit team, work on the automation of various maintenance
tasks. One of them is creating the Bodhi updates. (See packit.dev for more
details.)
* Our users can use Packit via CLI and use their identity for Bodhi
connections. With this, it's not nice, but doable to open a web-browser.
(Not sure how this works in the containerised use-cases.)
* But newly, we support this job in our service that uses `packit` FAS user
to create the updates. Here, it's not possible to open any browser.

So:
* Is there some way to get/generate some token that can be used instead of
doing this browser workflow?
* Do I get it right from what you wrote about `save_override` that we can
generate the session token elsewhere and reuse it in the service? Do you
have some details on how this works so we can start working on the move?
* For other Fedora systems, we use Kerberos authentication, are there some
plans to add it?
* Ideally, I would like to see it solved also for our CLI users, but at
least for Packit's service as a special case.

Thank you in advance for any tips or suggestions!
František Lachman

(CCing the Packit's mailing list.)





On Wed, Apr 6, 2022 at 12:38 PM Aurelien Bompard 
wrote:

> Hey everyone!
>
> Bodhi 6.0 will be published in a few days, and deployed to production a
> couple weeks after the Fedora release. It has backwards-incompatible
> changes, here's what you need to know.
>
> == Authentication ==
> Bodhi gained support for OpenID Connect (OIDC) authentication, like most
> of Fedora's webapps. OpenID still works but is not the default, you can
> access it by using `/login?method=openid` as the login URL.
>
> Version 6.0 of the Bodhi client uses only OIDC, plain OpenID support has
> been dropped. Version 5.7.5 of the Bodhi client, however, uses the new
> OpenID login URL and has been available for about a month now, you'll need
> at least version 5.7.5 to use the Bodhi client with the updated server.
>
> The client's API has changed, so if you have a piece of code that imports
> from `bodhi.client`, you'll have to update it to use the new API, and in
> the meantime use version 5.7.5.
>
> As a user of the `bodhi` CLI, you'll notice that the `--username` and
> `--password` options have disappeared. Instead the Bodhi client will ask
> you to open your browser to a URL to authenticate. The authentication
> tokens will be saved and you'll be able to use the `bodhi` CLI without
> authenticating afterwards (or non-interactively).
>
> == Code reorganization ==
> The Bodhi source code has been reorganized to drop the hacks used in
> `setup.py` to support sub-projects. Instead, `bodhi-server`, `bodhi-client`
> and `bodhi-messages` are now actual Python package directories in the repo.
> The import path has not changed.
>
> Bodhi's Python project metadata and dependencies are now managed with
> Poetry .
>
> == Other changes ==
> - Serialized `Release` objects sent in the messages don't contain the
> `composes` property anymore
> - The `koji-build-group.build.complete` messages now contain an `update`
> property
> - In the Bodhi client API, the `save_override()` method has been extended
> to allow setting the expiration date directly
> - Misc bug fixes
>
>
> If you have any questions, feel free to ask the Bodhi team in our matrix
> room: .
> If you are importing the bodhi client code in your app/script, or using
> the bodhi client in an "unusual" manner, we'll help you migrate.
>
> Thanks!
>
> Aurélien Bompard
> ___
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Packit in 2021

[Frantisek Lachman]

Hello all!

We would like to share with you what happened in Packit last year. Here,
two blog posts sum it up for you:

* https://packit.dev/posts/2021-features/
* https://packit.dev/posts/2021-in-numbers/

Thank all of you who has helped us to achieve that!

On behalf of the Packit team,
František
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Non responsive packager: usercont

[Frantisek Lachman]

Hi,

The Bugzilla account has been created for the usercont user. I hope it is
not a problem that we use a mailing list as an email address for that
account.

Regards,
František

On Mon, Jul 27, 2020 at 11:21 AM Frantisek Lachman 
wrote:

> Hi Pierre,
>
> I am really sorry about that. This user is used for automation run by our
> team (https://github.com/user-cont and https://github.com/packit-service/).
> I'll take a look into that.
>
> František
>
> On Mon, Jul 27, 2020 at 10:44 AM Pierre-Yves Chibon 
> wrote:
>
>> Good Morning Everyone,
>>
>> I have been trying to contact packagers without a proper bugzilla account
>> associated with their FAS email for a while now. The first email to
>> devel-announce
>> is from June 13th [1].
>>
>> This is a requirement for packagers which is mentioned at:
>>
>> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account
>>
>> Since then a number of packagers have fixed their situation but that user
>> did not.
>>
>> Currently I see:
>> usercont is maintaining rpms/colin
>> usercont is maintaining rpms/conu
>> usercont is maintaining rpms/packit
>> usercont is maintaining rpms/python-docker
>> usercont is maintaining rpms/python-ogr
>> usercont is maintaining rpms/rudesocket
>>
>>
>> I am hereby starting the non-responsive procedure for that user.
>>
>> Does someone know how to contact them?
>>
>> Failing to contact them, I will be asking FESCo to orphan the packages.
>>
>>
>> Thanks in advance for your help,
>>
>> Pierre
>>
>>
>> [1]
>> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/HDK6TTRXN7BQTYNSOR3TA5HMMKWQ5UQT/
>> ___
>> 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
>>
>
___
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: Non responsive packager: usercont

[Frantisek Lachman]

Hi Pierre,

I am really sorry about that. This user is used for automation run by our
team (https://github.com/user-cont and https://github.com/packit-service/).
I'll take a look into that.

František

On Mon, Jul 27, 2020 at 10:44 AM Pierre-Yves Chibon 
wrote:

> Good Morning Everyone,
>
> I have been trying to contact packagers without a proper bugzilla account
> associated with their FAS email for a while now. The first email to
> devel-announce
> is from June 13th [1].
>
> This is a requirement for packagers which is mentioned at:
>
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account
>
> Since then a number of packagers have fixed their situation but that user
> did not.
>
> Currently I see:
> usercont is maintaining rpms/colin
> usercont is maintaining rpms/conu
> usercont is maintaining rpms/packit
> usercont is maintaining rpms/python-docker
> usercont is maintaining rpms/python-ogr
> usercont is maintaining rpms/rudesocket
>
>
> I am hereby starting the non-responsive procedure for that user.
>
> Does someone know how to contact them?
>
> Failing to contact them, I will be asking FESCo to orphan the packages.
>
>
> Thanks in advance for your help,
>
> Pierre
>
>
> [1]
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/HDK6TTRXN7BQTYNSOR3TA5HMMKWQ5UQT/
> ___
> 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
>
___
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