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/micr
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, 20
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 `cha
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 cl
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.fed
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" o
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 un
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
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 wa
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 almo
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 imp
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 t
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 rem
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"
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 provi
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
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
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
> a
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 cach
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.
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
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
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, Fed
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 t
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, mer
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 up
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-
27 matches
Mail list logo
