Mock v5.6 and mock-core-configs v40.4 release

[Jakub Kadlcik]

Hello maintainers,

We released a new version of Mock, the chroot build environment manager for
building RPMs, and a new version of mock-core-configs.

The notable changes are big performance improvements for bash completion,
many bugfixes, new Circle Linux 9 configs, and more.

Full release notes:
https://rpm-software-management.github.io/mock/Release-Notes-5.6

The updated packages are in Bodhi:

Mock:

F39: https://bodhi.fedoraproject.org/updates/FEDORA-2024-95b3c15bef
F40: https://bodhi.fedoraproject.org/updates/FEDORA-2024-d0ea076533
EL8: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-0c91de6fa2
EL9: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-e79e59202c

mock-core-configs:

F39: https://bodhi.fedoraproject.org/updates/FEDORA-2024-e927925b96
F40: https://bodhi.fedoraproject.org/updates/FEDORA-2024-d835607b8d
EL8: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-da4c3f
EL9: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-0c1c785d5a

Happy building!
--
___
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

User SSH access to Copr builders

[Jakub Kadlcik]

Hello,
this may be a useful feature for many people, so I wanted to announce it
separately.

Debugging failed Copr builds became much easier with the last release.
https://docs.pagure.org/copr.copr/release-notes/2024-03-07.html

You can now enable SSH access to the builder, connect using your pubkey,
and run any commands you need to debug the issue. Everything is explained
in my blog post.
https://frostyx.cz/posts/ssh-access-to-copr-builders

Jakub
--
___
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

Fedora Review feature in Copr and Fedora Review Service work again

[Jakub Kadlcik]

Hello fellow package maintainers,
we had multiple reports over the last weeks that the fedora-review feature
in Copr produces empty review.txt templates for F40 and Fedora Rawhide. And
as a consequence the Fedora Review Service points to empty review.txt files.

The issue is in the fedora-review tool and it is related to the migration
to DNF5 in new Fedora versions. I am proposing the following fix
https://pagure.io/FedoraReview/pull-request/513 but I decided not to wait
for it to get merged and released.

I applied the proposed patch on Copr builders so everything should work as
expected now. My apologies once again for the downtime.

Jakub
--
___
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: Announce: Log Detective - AI tool to analyze build logs failures

[Jakub Kadlcik]

Hello all,
I recorded a very short video showing how you can contribute to the Log
Detective project.

https://www.youtube.com/watch?v=_-O7ryKCnlQ

Any help will be greatly appreciated :-)
Jakub



On Wed, Jan 17, 2024 at 8:26 PM Jiri Kyjovsky  wrote:

> Hello Tristan,
>
> We store the data in json format. You can access and download the data
> directly at our main page at the bottom - "Download collected data". Or via
> https://log-detective.com/download
>
> Cheers
> Jiri
> --
> ___
> 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

Cached Package Review Tracker - Tickets that passed automated review

[Jakub Kadlcik]

Hello,
if you use the Cached Package Review Tracker
https://fedoraproject.org/PackageReviewStatus/
there is a new "feature" that you may find useful.

Fedora Review Service runs the fedora-review tool on every new Bugzilla
ticket. If no errors are found, the ticket is marked with a special
keyword. Such tickets are then displayed in the "New tickets that passed CI
checks" section of the cached tracker.
https://fedoraproject.org/PackageReviewStatus/triaged.html

They are also highlighted in the "New Fedora tickets" section
https://fedoraproject.org/PackageReviewStatus/reviewable.html
(see the color legend)

The presumption is - if a ticket passes all fedora-review checks, it is
probably in relatively good shape and the package review could be quick and
simple.

Hopefully, you will find it useful.
Jakub
--
___
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: fedora-distro-aliases - The easiest way to get numbers of active Fedora releases

[Jakub Kadlcik]

I published version 1.2 which doesn't depend on bodhi-client anymore. It is
now on PyPI and Bodhi updates are in testing.

On Tue, Jan 23, 2024 at 12:59 PM Jakub Kadlcik  wrote:

> Thank you for the feedback Stephen,
> I didn't realize how many and how complicated dependencies the bodhli
> client package has. It was no problem when installing via DNF but you are
> right with the pip installation -
> https://github.com/rpm-software-management/fedora-distro-aliases/issues/3
>
> Please subscribe the issue, I will fix it soon :-)
>
> On Fri, Jan 19, 2024 at 8:34 PM Stephen Gallagher 
> wrote:
>
>> On Thu, Jan 18, 2024 at 10:32 AM Stephen Gallagher 
>> wrote:
>> >
>> > On Wed, Jan 17, 2024 at 5:58 AM Jakub Kadlcik 
>> wrote:
>> > >
>> > > Hello,
>> > > I just wanted to quickly announce a small project I did in
>> collaboration with the Packit folks.
>> > >
>> > > Do you have some tools or services that perform actions on all
>> currently active Fedora releases? And do you have to manually update their
>> list every time a new Fedora release is branched or EOLed? The
>> fedora-distro-aliases will make your life easier.
>> > >
>> > > https://github.com/rpm-software-management/fedora-distro-aliases
>> > >
>> > > It defines aliases such as `fedora-stable`, `epel-all`,
>> `fedora-latest`, etc. To evaluate them, it queries Bodhi, so they are
>> always up-to-date (but the tradeoff is that it requires an internet
>> connection). There are multiple examples in the project README but the
>> usage is simple, e.g.:
>> > >
>> > > >>> from fedora_distro_aliases import get_distro_aliases
>> > > >>> aliases = get_distro_aliases()
>> > > >>> [x.namever for x in aliases["fedora-all"]]
>> > > ['fedora-38', 'fedora-39', 'fedora-rawhide']
>> > >
>> > > The package is already in Fedora, give it a shot,
>> >
>> > Thanks! I'll look into updating
>> > https://github.com/sgallagher/get-fedora-releases-action with this.
>>
>> Scratch that, it appears that `pip3 install fedora_distro_aliases`
>> requires installing krb5 devel packages (and compiling it) on the
>> target system before it can be used. This had the effect in my testing
>> of increasing the time spent running my Action from ~10s to ~240s,
>> which is too big of an increase. Is there a good reason why you're
>> using the complete BodhiClient interface instead of just doing simple
>> HTTP requests against https://bodhi.fedoraproject.org/releases ?
>> --
>> ___
>> 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: fedora-distro-aliases - The easiest way to get numbers of active Fedora releases

[Jakub Kadlcik]

Thank you for the feedback Stephen,
I didn't realize how many and how complicated dependencies the bodhli
client package has. It was no problem when installing via DNF but you are
right with the pip installation -
https://github.com/rpm-software-management/fedora-distro-aliases/issues/3

Please subscribe the issue, I will fix it soon :-)

On Fri, Jan 19, 2024 at 8:34 PM Stephen Gallagher 
wrote:

> On Thu, Jan 18, 2024 at 10:32 AM Stephen Gallagher 
> wrote:
> >
> > On Wed, Jan 17, 2024 at 5:58 AM Jakub Kadlcik 
> wrote:
> > >
> > > Hello,
> > > I just wanted to quickly announce a small project I did in
> collaboration with the Packit folks.
> > >
> > > Do you have some tools or services that perform actions on all
> currently active Fedora releases? And do you have to manually update their
> list every time a new Fedora release is branched or EOLed? The
> fedora-distro-aliases will make your life easier.
> > >
> > > https://github.com/rpm-software-management/fedora-distro-aliases
> > >
> > > It defines aliases such as `fedora-stable`, `epel-all`,
> `fedora-latest`, etc. To evaluate them, it queries Bodhi, so they are
> always up-to-date (but the tradeoff is that it requires an internet
> connection). There are multiple examples in the project README but the
> usage is simple, e.g.:
> > >
> > > >>> from fedora_distro_aliases import get_distro_aliases
> > > >>> aliases = get_distro_aliases()
> > > >>> [x.namever for x in aliases["fedora-all"]]
> > > ['fedora-38', 'fedora-39', 'fedora-rawhide']
> > >
> > > The package is already in Fedora, give it a shot,
> >
> > Thanks! I'll look into updating
> > https://github.com/sgallagher/get-fedora-releases-action with this.
>
> Scratch that, it appears that `pip3 install fedora_distro_aliases`
> requires installing krb5 devel packages (and compiling it) on the
> target system before it can be used. This had the effect in my testing
> of increasing the time spent running my Action from ~10s to ~240s,
> which is too big of an increase. Is there a good reason why you're
> using the complete BodhiClient interface instead of just doing simple
> HTTP requests against https://bodhi.fedoraproject.org/releases ?
> --
> ___
> 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

fedora-distro-aliases - The easiest way to get numbers of active Fedora releases

[Jakub Kadlcik]

Hello,
I just wanted to quickly announce a small project I did in collaboration
with the Packit folks.

Do you have some tools or services that perform actions on all currently
active Fedora releases? And do you have to manually update their list every
time a new Fedora release is branched or EOLed? The fedora-distro-aliases
will make your life easier.

https://github.com/rpm-software-management/fedora-distro-aliases

It defines aliases such as `fedora-stable`, `epel-all`, `fedora-latest`,
etc. To evaluate them, it queries Bodhi, so they are always up-to-date (but
the tradeoff is that it requires an internet connection). There are
multiple examples in the project README but the usage is simple, e.g.:

>>> from fedora_distro_aliases import get_distro_aliases
>>> aliases = get_distro_aliases()
>>> [x.namever for x in aliases["fedora-all"]]
['fedora-38', 'fedora-39', 'fedora-rawhide']

The package is already in Fedora, give it a shot,
Jakub
--
___
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: Fedora Review Service and setting the AutomationTriaged keyword

[Jakub Kadlcik]

Thank you for the feedback Dominik,

> Cool! Go for it.
> Great idea.

I am going for it then :-)

On Sat, Dec 9, 2023 at 10:20 PM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> On Saturday, 09 December 2023 at 19:32, Jakub Kadlcik wrote:
> > Hello,
> > a year ago I announced
> > <
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/E4TT2PEOSITJ4PJP44L2GQUU4CA6R6B3/#ZJGYOMU6I7LEETQ4YEH6ZJBSC5VEM653
> >
> > and
> > launched the Fedora Review Service
> > <https://github.com/FrostyX/fedora-review-service>.
> > Nobody complained that it is annoying, and I am getting pings from people
> > when there is an outage, so I consider this endeavor to be a success :-)
>
> Yes, it is very useful. I like it a lot.
>
> > Since its last release, the service parses and shows recommendations
> based
> > on the fedora-review.json
> > <https://github.com/FrostyX/fedora-review-service/pull/33> output.
> There is
> > a nice secondary use of this feature - we can do something when no errors
> > are found. My plan is to set the `AutomationTriaged` Bugzilla keyword for
> > such tickets. Or any other keyword that you would prefer. As a
> follow-up, I
> > want to unleash the service on all open review tickets, so that even
> > tickets that predate the service can obtain the `AutomationTriaged`
> keyword.
> >
> > RFE https://github.com/FrostyX/fedora-review-service/issues/13
>
> Cool! Go for it.
>
> > The endgame will be adding "CI passing tickets" section to the Cached
> > Package Review Tracker <https://fedoraproject.org/PackageReviewStatus/>
> and/or
> > adding some special row color for tickets that passed the automated
> review
> > to already existing sections
> > <https://fedoraproject.org/PackageReviewStatus/reviewable.html>.
>
> Great idea.
>
> > My motivation for this feature is to make life easier for reviewers. They
> > will be able to focus on tickets that passed an automated review and
> > therefore are more likely to be in an (almost) acceptable state.
> >
> > What do you think?
>
> This is excellent work. Thank you so much for doing this.
>
> Regards,
> Dominik
> --
> Fedora   https://fedoraproject.org
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
> -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> --
> ___
> 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

Fedora Review Service and setting the AutomationTriaged keyword

[Jakub Kadlcik]

Hello,
a year ago I announced

and
launched the Fedora Review Service
.
Nobody complained that it is annoying, and I am getting pings from people
when there is an outage, so I consider this endeavor to be a success :-)

Since its last release, the service parses and shows recommendations based
on the fedora-review.json
 output. There is
a nice secondary use of this feature - we can do something when no errors
are found. My plan is to set the `AutomationTriaged` Bugzilla keyword for
such tickets. Or any other keyword that you would prefer. As a follow-up, I
want to unleash the service on all open review tickets, so that even
tickets that predate the service can obtain the `AutomationTriaged` keyword.

RFE https://github.com/FrostyX/fedora-review-service/issues/13

The endgame will be adding "CI passing tickets" section to the Cached
Package Review Tracker  and/or
adding some special row color for tickets that passed the automated review
to already existing sections
.

My motivation for this feature is to make life easier for reviewers. They
will be able to focus on tickets that passed an automated review and
therefore are more likely to be in an (almost) acceptable state.

What do you think?
Jakub
--
___
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: fedora-review workarounds for dnf5

[Jakub Kadlcik]

Hello Sandro,

> I noticed that in f39 builds in Copr the directory containing the
> results is now named after the package. Comparing that to the
> "traditional" fedora-review directory in f38 builds, I miss the
> `licensecheck.txt` file.

It suddenly started happening and I don't know what is to blame yet.
You can follow

https://github.com/FrostyX/fedora-review-service/issues/28
https://pagure.io/FedoraReview/issue/486

I plan to work on it as soon as I can.

Jakub

On Wed, Jul 26, 2023 at 1:34 AM Sandro  wrote:
>
> On 25-07-2023 04:47, Michel Alexandre Salim wrote:
> > Once this lands in F38, Fedora Review Service should be fixed, unless
> > I'm missing something.
>
> First of all, thanks for bringing fedora-review back. I rely on it quite
> a bit reviewing my own packages as well as for official reviews.
>
> I noticed that in f39 builds in Copr the directory containing the
> results is now named after the package. Comparing that to the
> "traditional" fedora-review directory in f38 builds, I miss the
> `licensecheck.txt` file.
>
> The contents of the fedora-review directory ($PACKAGE_NAME) in f39 look
> more alike to a local fedora-review, which is fine. But
> `licensecheck.txt` is invaluable for checking licenses of generated
> files. Just now I finished a review using the f38 build, which detected
> two additional licenses in generated files, that went unnoticed by the
> submitter.
>
> Can `licensecheck.txt` be added back to f39 fedora-review runs, please?
>
> -- Sandro
> ___
> 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: fedora-review workarounds for dnf5

[Jakub Kadlcik]

Thank you very much Michel for going through the release.
It couldn't be easy.

There is a reported bug in Bodhi, so it will need some minor fixups
but we are close. Really looking forward to it.

Jakub

On Tue, Jul 25, 2023 at 4:48 AM Michel Alexandre Salim
 wrote:
>
> Hi all,
>
> On Mon, Jul 17, 2023 at 10:54:43AM -0600, Jerry James wrote:
> > Like many of you, I have been quite inconvenienced because of
> > dnf5-related breakage of fedora-review.  I've been monkeying with it
> > today and finally got a successful run of fedora-review after making
> > the following changes [*].
> >
> I'm happy (and relieved) to say that a fixed fedora-review is ready for
> testing:
>
> https://bodhi.fedoraproject.org/updates/?search==fedora-review=pending=testing
>
> This uses Jakub Kadlcik's initial PR to use dnf-3 instead of dnf, so we
> don't necessarily commit ourselves to using DNF 5 until the we know for
> sure if Fedora 39 will ship with DNF 5 or not.
>
> Thanks also to Benjamin A. Beasley, Miro Hrončok, Benson Muite, Jitka
> Plesnikova, Pavel Raiskup, and Sérgio M. Basto for contributing changes
> shipped in this release.
>
> 0.10.0 was supposed to have gone out 3 months ago, but blocked by
> changes in setuptools/distutils causing our release script to generate
> an incomplete tarball. I've done a more thorough fix that will hopefully
> hold until we rewrite our build process be PEP 517 compliant for the
> next release.
>
> Once this lands in F38, Fedora Review Service should be fixed, unless
> I'm missing something.
>
> Best regards,
>
> --
> Michel Alexandre Salim
> identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
> ___
> 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: fedora-review workarounds for dnf5

[Jakub Kadlcik]

Hello Jerry,
I proposed a workaround a few days ago
https://pagure.io/FedoraReview/pull-request/485

but your patch looks like a proper fix. I'll try it and merge to the
fedora-review codebase.

Does anybody know what was the purpose of --resolve and if it will be
no problem when we remove it?

Jakub

On Tue, Jul 18, 2023 at 12:39 AM Sandro  wrote:
>
> On 17-07-2023 20:39, Jerry James wrote:
> > On Mon, Jul 17, 2023 at 10:54 AM Jerry James  wrote:
> >> Like many of you, I have been quite inconvenienced because of
> >> dnf5-related breakage of fedora-review.  I've been monkeying with it
> >> today and finally got a successful run of fedora-review after making
> >> the following changes [*].
> >>
> >> 1. Edit /etc/mock/templates/fedora-rawhide.tpl.  Change:
> >>
> >> config_opts['package_manager'] = 'dnf'
> >>
> >> to:
> >>
> >> config_opts['package_manager'] = 'dnf5'
> >>
> >> 2. Run 'mock -r fedora-rawhide-x86_64 --scrub=bootstrap'
> >>
> >> 3. Edit /usr/lib/python3.11/site-packages/FedoraReview/deps.py.  Change 
> >> line
> >> 83 from:
> >>
> >>  "dnf repoquery -q -C --requires --resolve " + " 
> >> ".join(list(set(pkgs))),
> >>
> >> to:
> >>
> >>  "dnf repoquery -q -C --requires " + " ".join(list(set(pkgs))),
> >>
> >> Change line 97 from:
> >>
> >>  name = line.rsplit(".", 2)[0]
> >>
> >> to:
> >>
> >>  name = resolve_one(line)[0].rsplit(".", 2)[0]
> >>
> >> Change line 286 from:
> >>
> >>  "dnf repoquery -C -l " + " ".join(list(set(pkgs))),
> >>
> >> to:
> >>
> >>  "dnf repoquery --files " + " ".join(list(set(pkgs))),
> >>
> >> Other changes may be needed.
> >>
> >> [*] Altering rpm-controlled files is generally a bad idea, and I do not
> >>  recommend it.  I am only doing so in this case because fedora-review 
> >> does
> >>  not work at all without these changes.  I understand that my changes 
> >> will
> >>  be overwritten the next time a mock-core-configs or fedora-review 
> >> update
> >>  is installed.
> >
> > Skip steps 1 and 2.  They are unnecessary.  Step 3 is all you need.
>
> Would that be a temporary solution for Copr as well? I mean for all
> rawhide builds? I quite miss not having fedora-review available there.
>
> -- Sandro
> ___
> 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: Auto-assign packager sponsors to tickets?

[Jakub Kadlcik]

I want to thank you all for the feedback.

Everything was already mentioned in the discussion so I am not going
to dig into details again. Just a quick summary for anyone who wants
TL;DR for this thread:

- I am not going to implement the original proposal or any variation of it
- Instead, I am going to automatically open an issue in the
package-sponsors tracker for new contributors after they receive
fedora-review+ on their first ticket. A link to this issue along with
some explanation will be automatically commented to their package
review Bugzilla ticket.
- You can follow the progress here
https://github.com/FrostyX/fedora-review-service/issues/18

Jakub

On Wed, Apr 5, 2023 at 8:51 AM Vitaly Zaitsev via devel
 wrote:
>
> On 04/04/2023 23:42, Kevin Fenzi wrote:
> > But then after a outcry... "We are reverting this change for now. More
> > details to follow."
>
> Yes, after a lot of negative feedback they (temporary?) reverted this
> change. Even their own vcpkg (package manager by Microsoft) uses these
> hashes to verify downloaded files.
>
> They said that after each download of the git tag archive, its contents
> are permanently stored on the content server, and all subsequent
> downloads will be performed by it. It consumes a lot of disk space.
>
> --
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.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
> 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

Non-responsive maintainer - rkuska

[Jakub Kadlcik]

Hello,
per the Non-responsive maintainer policy
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers

I am sending this email. We (copr-sig) would like to (co)maintain the
python-flask-whooshee package but @rkuska can't give us permission
because he lost access to his FAS account.

We talked about this off-list, so this is basically just FYI for others.

RHBZ ticket: https://bugzilla.redhat.com/show_bug.cgi?id=2042681

Jakub
___
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: Auto-assign packager sponsors to tickets?

[Jakub Kadlcik]

Thank you all for the feedback.

> The bottom line is that package reviews can be quite time consuming.  I
> don't think the issue is with sponsorship itself.

Sorry Jason, I probably didn't communicate my idea as clearly as I
should. My intention wasn't to assign sponsors to review tickets and
make them do the actual review. I am trying to address the situation
where a ticket already has a fedora-review+ flag but it was given by a
reviewer who is not a sponsor.


> You're saying that tickets were properly filed with the
> packager-sponsors tracker and those were not addressed?  I checked the
> open tickets before responding.  I didn't see anything.  If tickets got
> closed without any action being taken, could you point out those
> tickets?  That would be a rather odd state of affairs

Not in the packager-sponsors tracker, I checked it out, and I must say
it is being processed flawlessly. Really good job there.
Reading the discussion, I think we discovered one of the main issues
elsewhere - We don't properly instruct new contributors to create a
ticket in the tracker.
This will be a big improvement:
https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/118

To point out the specific tickets that weren't addressed, they are here:
https://fedoraproject.org/PackageReviewStatus/needsponsor.html


> But I think this is not outreachy enough.

I agree, so my next step will be improving the fedora-review-service
to post a comment about how to find a sponsor, in case fedora-review+
flag was given by a non-sponsor. More info in this RFE:
https://github.com/FrostyX/fedora-review-service/issues/18


> From this thread I get
> the opposite impression, that Pagure tickets are processed quickly and
> FE-NEEDSPONSOR blockers are not looked at. If so, I propose the policy
> is updated to ask for a Pagure ticket in every case.

I get the same impression and I would agree with Otto's proposal to
get rid of the FE-NEEDSPONSOR entirely. Apart from it not being
processed as effectively as the package-sponsor repo tickets, the
FE-NEEDSPONSOR is confusing anyway (it is set to a review ticket but
the ticket doesn't need to be sponsored, the contributor does. That
becomes weird when the contributor has more tickets at the same time
and so on). But if I understand correctly, FESCo needs to be involved
and therefore this would be a long-term goal.


> Please exclude me from such spam.

I was finally able to find some numbers and it turns out, we
successfully sponsor ~100 people a year. That is much more than I
expected, so I now understand your point. We are also much more
effective than I thought (well you guys are).


> Sure, just plumb the end of the review process (accepted ticket) to feed
> right into the sponsor process (let the sponsors know, preferably via
> the tracker).  But I don't think that assigning unreviewed tickets to
> random sponsors is the right way.

This can work and will be easy to implement as well. I like the idea,
we can try it :-)

Jakub



On Mon, Apr 3, 2023 at 11:57 PM Otto Liljalaakso
 wrote:
>
> Jason Tibbitts kirjoitti 3.4.2023 klo 20.09:
> >> Miroslav Suchý  writes:
> >
> > In any case, what I wrote was the procedure I documented it when I set
> > it up.  If all of that documentation was lost, then I don't know what to
> > say but that's not what was intended.
> >
> > I drove the change that made this happen.  I made sure the documentation
> > (in the wiki at the time) referenced the procedure.  If that was lost
> > after the time when I was able to be very active in Fedora, then that's
> > a sad state of affairs and I don't know why that would happen, but it
> > would be really good if it could un-happen.  Did FESCo revert the policy
> > change or something?
>
> Somewhat recently, the Packager sponsor policy [1] has been rewritten.
> The history is that moved content over from the wiki to the Package
> Maintainer Docs, then edited it to make things more clear. Later, I
> realized that what I edited was actually intended to be a FESCo-approved
> policy, just not clearly marked as such in the wiki and editable by
> anyone. So I went to FESCo to get the material officially approved - see
> the pull request [2].
>
> The result of this is that it is currently a FESCo policy that for new
> packages, the sponsorship is requested by blocking the FE-NEEDSPONSOR
> Bugzilla, and for all other paths by filing a Pagure ticket. The reason
> why I wrote the pull request like that is that at that time, there was
> discussion about this on devel where I proposed using Pagure tickets for
> new packages also, but got negative feedback [3].
>
> The gist of that negative feedback was "very few sponsors are looking at
> the Pagure tickets, we cannot process that many". From this thread I get
> the opposite impression, that Pagure tickets are processed quickly and
> FE-NEEDSPONSOR blockers are not looked at. If so, I propose the policy
> is updated to ask for a Pagure ticket in every case.
>
> [1]: 

Re: Auto-assign packager sponsors to tickets?

[Jakub Kadlcik]

> It absoletely does. ;)

And it even allows us to retrospectively see how many packagers were
sponsored in the last month/year/...
https://gist.github.com/FrostyX/47defa18348fbb917e73d7b2e7660ca2

Fedora-messaging is awesome :-)

On Mon, Apr 3, 2023 at 10:33 PM Kevin Fenzi  wrote:
>
> On Mon, Apr 03, 2023 at 01:52:49PM -0500, Jason Tibbitts wrote:
> > > Miroslav Suchý  writes:
> >
> > > No, I'm not saying that. Somebody has enough courage to open the
> > > package review, discuss it, get to the point that the package review
> > > was approved. But did not have the courage to reach sponsors. It was
> > > road block for them.
> >
> > That's an odd case, I suppose.  I have trouble understand how someone
> > could make it through all of that process and then not be able to ask
> > for one more thing, and I would tend to attribute most issues in that
> > area to process overload and lack of documentation.  But then, that
> > points out a possibility for automation: When the review flag gets set
> > to '+' on a NEEDSPONSOR bug, automatically alert the sponsors.  If this
> > can file the ticket at https://pagure.io/packager-sponsors/ then great;
> > otherwise there is a mailing list, though it's much easier to lose a
> > random list message.
> >
> > I have no idea how to actually make that happen, unless bugzilla things
> > generate messages on the bus.
>
> It absoletely does. ;)
>
> https://apps.fedoraproject.org/datagrepper/raw?rows_per_pager=20=bugzilla
>
> Someone could write a toddler that listens for those and acts on the
> ones desired. Just like the current one that listens for scm requests.
>
> kevin
> ___
> 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: Auto-assign packager sponsors to tickets?

[Jakub Kadlcik]

I tried to get some numbers to see how many packagers we sponsor each
year but FAS tells me only group members but not when they joined the
group. Do any of you at least have a rough estimate of what number are
we talking about? I wouldn't propose any auto-assign system for
package reviews because there is thousand of them each year. That
would be insane. But how many new contributors that need to be
sponsored do we have each year? My guess is that not even every
sponsor would get a ticket within the year.

Jakub

On Sun, Apr 2, 2023 at 5:07 PM Jakub Kadlcik  wrote:
>
> > If they wait for months, I think they don't want to be sponsored.
>
> I respectfully disagree here, IMHO we communicate a message that a
> sponsor will find the contributor, not the other way around. Just so I
> don't repeat the same message in my own words, everything that
> Miroslav said, sounds true to me.
>
> > Please exclude me from such spam.
>
> Sure, no problem with me. As I said in my initial proposal, I'd
> provide an easy way to opt out (probably multiple ways, so it is
> convenient for everybody).
>
> > I don't think it's fair to expect that all sponsors are available to do 
> > this at any time.
>
> Well sure, I agree. Mentoring somebody is a time commitment and nobody
> has sponsoring people as the #1 priority. But as I said in the
> proposal "If a sponsor is not able or willing to work on a ticket,
> they could either set NEEDINFO on another sponsor or just drop
> themselves. The ticket would then get a new sponsor next week" - to me
> this sounds very reasonable.
>
> Jakub
>
> On Sun, Apr 2, 2023 at 4:12 PM Miroslav Suchý  wrote:
> >
> > Dne 02. 04. 23 v 11:54 Vitaly Zaitsev via devel napsal(a):
> >
> > I'm always willing to review and sponsor new maintainers, but they need to 
> > show explicit consent by posting on IRC/Matrix/ML or direct email.
> >
> > Let me check the history of
> >
> >   
> > https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/#how_to_find_a_sponsor
> >
> > Right now we tell users to:
> >
> > Usually, a sponsor finds you through your sponsorship request in Bugzilla 
> > or the packager sponsors pagure instance. In case you are waiting to be 
> > sponsored for longer than desirable, take a look at Sponsors page. It will 
> > help you find the right sponsor for you based on programming language 
> > preference, domains of interest, native language, and other criteria.
> >
> > This is not there for long time. Actually since 2021 when Jakub wrote that 
> > "Sponsor page". Previously there was:
> >
> > If you are submitting a new package for review in Bugzilla,
> > you can make the review request block the
> > https://bugzilla.redhat.com/show_bug.cgi?id=FE-NEEDSPONSOR[FE-NEEDSPONSOR] 
> > tracking bug.
> >
> > Otherwise, you can file a ticket in the
> > https://pagure.io/packager-sponsors/[sponsors ticketing system].
> >
> > So previously - and even now - we tell newcomers to to block FE-NEEDSPONSOR 
> > and wait. And only if they wait too long (whatever it means) to start 
> > looking for sponsors directly.
> >
> > I personally think that Jakub's proposal is great and I welcome it. Not 
> > everyone is brave to initiate a conversation and asks for being sponsored. 
> > We have to realize it often means that junior developer has to reach senior 
> > developer and juniors often hesitate to do this step. This proposal remove 
> > one road blocks for juniors.
> >
> > If other people does not find it useful, then I propose to at least alter 
> > our documentation and tell users to start looking for sponsor immediately 
> > after blocking FE-NEEDSPONSOR.
> >
> > Miroslav
> >
> >
> > ___
> > 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: Auto-assign packager sponsors to tickets?

[Jakub Kadlcik]

> If they wait for months, I think they don't want to be sponsored.

I respectfully disagree here, IMHO we communicate a message that a
sponsor will find the contributor, not the other way around. Just so I
don't repeat the same message in my own words, everything that
Miroslav said, sounds true to me.

> Please exclude me from such spam.

Sure, no problem with me. As I said in my initial proposal, I'd
provide an easy way to opt out (probably multiple ways, so it is
convenient for everybody).

> I don't think it's fair to expect that all sponsors are available to do this 
> at any time.

Well sure, I agree. Mentoring somebody is a time commitment and nobody
has sponsoring people as the #1 priority. But as I said in the
proposal "If a sponsor is not able or willing to work on a ticket,
they could either set NEEDINFO on another sponsor or just drop
themselves. The ticket would then get a new sponsor next week" - to me
this sounds very reasonable.

Jakub

On Sun, Apr 2, 2023 at 4:12 PM Miroslav Suchý  wrote:
>
> Dne 02. 04. 23 v 11:54 Vitaly Zaitsev via devel napsal(a):
>
> I'm always willing to review and sponsor new maintainers, but they need to 
> show explicit consent by posting on IRC/Matrix/ML or direct email.
>
> Let me check the history of
>
>   
> https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/#how_to_find_a_sponsor
>
> Right now we tell users to:
>
> Usually, a sponsor finds you through your sponsorship request in Bugzilla or 
> the packager sponsors pagure instance. In case you are waiting to be 
> sponsored for longer than desirable, take a look at Sponsors page. It will 
> help you find the right sponsor for you based on programming language 
> preference, domains of interest, native language, and other criteria.
>
> This is not there for long time. Actually since 2021 when Jakub wrote that 
> "Sponsor page". Previously there was:
>
> If you are submitting a new package for review in Bugzilla,
> you can make the review request block the
> https://bugzilla.redhat.com/show_bug.cgi?id=FE-NEEDSPONSOR[FE-NEEDSPONSOR] 
> tracking bug.
>
> Otherwise, you can file a ticket in the
> https://pagure.io/packager-sponsors/[sponsors ticketing system].
>
> So previously - and even now - we tell newcomers to to block FE-NEEDSPONSOR 
> and wait. And only if they wait too long (whatever it means) to start looking 
> for sponsors directly.
>
> I personally think that Jakub's proposal is great and I welcome it. Not 
> everyone is brave to initiate a conversation and asks for being sponsored. We 
> have to realize it often means that junior developer has to reach senior 
> developer and juniors often hesitate to do this step. This proposal remove 
> one road blocks for juniors.
>
> If other people does not find it useful, then I propose to at least alter our 
> documentation and tell users to start looking for sponsor immediately after 
> blocking FE-NEEDSPONSOR.
>
> Miroslav
>
>
> ___
> 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: Auto-assign packager sponsors to tickets?

[Jakub Kadlcik]

Oh, and I forgot one important thing. Any sponsor that would disagree
with being assigned tickets this way would be able to opt out by
adding something like `auto_assign: false` to their sponsor.yaml
https://github.com/FrostyX/fedora-sponsors#b-your-personal-config-on-fedorapeopleorg

Jakub

On Sat, Apr 1, 2023 at 11:17 PM Jakub Kadlčík  wrote:
>
> Hello,
>
> I've set myself a goal to improve the package review process. My first
> step was creating https://docs.pagure.org/fedora-sponsors , I am
> currently working on https://github.com/FrostyX/fedora-review-service
> and contribute to the `fedora-review` tool. I have some ideas about
> what to do next, and now I'd like to discuss one of them.
>
> Currently, we have 31 people waiting to be sponsored
> https://fedoraproject.org/PackageReviewStatus/needsponsor.html
> many of them waiting for months. To get to the point of waiting to be
> sponsored, all of these people invested their time to learn the basics
> of RPM packaging and went through the tedious process of a package
> review without quitting. It's not very nice of us to let them wait for
> an indefinite amount of time without a reply after all of this.
>
> I believe there is a technical solution to this problem, so I'd like
> to write a script that would:
>
> - Be run weekly
> - Take a small number of active sponsors (say 5 of them, or maybe 10%
>   of them) and give each of them one of the waiting tickets
> - Technically, it would be done by setting NEEDINFO on the ticket
> - If a sponsor was already given one ticket, he wouldn't get another
> - It could prioritize sponsors who didn't get tickets for the longest
>   time
> - It could consider sponsors' interests
>   https://docs.pagure.org/fedora-sponsors/interests
>
> Additionally:
>
> - If a sponsor is not able or willing to work on a ticket, they could
>   either set NEEDINFO on another sponsor or just drop themselves. The
>   ticket would then get a new sponsor next week
> - After a month without a response to a NEEDINFO, another sponsor
>   would be assigned
>
> We currently have 37 active sponsors and 31 tickets waiting to be
> sponsored, so the whole queue should get processed within a couple of
> weeks and every sponsor should get only one ticket. After that I have
> no idea how often will every sponsor be bothered. Maybe once a year?
>
> What do you think? Would you be okay with a system like this?
> Please forward to sponsors that you know, if there is no strong
> disagreement, I'll proceed with the implementation.
>
> Jakub
___
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: Fedora Linux 38 branched

[Jakub Kadlcik]

Hello Tomas,
thank you for the announcement.

We also branched Fedora 38 in Copr so that everybody can submit builds
for it by now. Also, all projects with the "Follow Fedora branching"
option configured in their project settings have F38 chroots
automatically enabled and they contain the last build results from
Fedora Rawhide before the branch.

Jakub

On Thu, Feb 9, 2023 at 8:14 PM Tomas Hrcka  wrote:
>
> Hi All,
>
> Fedora Linux 38 has now been branched, please be sure to do a git pull
> --rebase to pick up the new branch, as an additional reminder
> rawhide/f39 has been completely isolated from previous releases, so
> this means that anything you do for f38 you also have to do in the
> rawhide branch and do a build there. There will be a Fedora Linux 38 compose
> and it'll appear in
> http://dl.fedoraproject.org/pub/fedora/linux/development/38/ once
> complete.
>
> Bodhi is currently enabled in the f38 branch like it is for rawhide,
> with automatic update creation. At the hit Beta change freeze point
> in the Fedora Linux 38 schedule[1] updates-testing will be enabled and
> manual bodhi updates will be required as in all stable releases.
>
> Two things to remember:
>
> 1. The modules will be built for a new platform:f39
> 2. F38/branched release is frozen right now until we get a successful
> compose, expect that your f38 builds won't be available immediately.
>
> Thanks for understanding.
> Tomas Hrcka
> Fedora Release Engineering
>
> [1] https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-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-annou...@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: Fedora Review Service

[Jakub Kadlcik]

Hello guys,
I just wanted to announce that the service is already deployed and
that I am trying to figure out all the quirks and ask you to please be
patient.

But you were faster :-)
Thank you for the reports, please ping me with anything more that you
find. I am also trying to monitor what is happening.

The issue that Miro found
https://bugzilla.redhat.com/show_bug.cgi?id=2133080#c19
was caused by an URL-encoded caret symbol in the package name, which
is IMHO a Copr bug. I already sent a PR
https://github.com/fedora-copr/copr/pull/2454

The issue that Frank found
https://bugzilla.redhat.com/show_bug.cgi?id=2119983
I am not sure, looks like a temporary unavailability of the URL
because when I resubmitted the package, it built successfully. Not
sure what should be done about this, I will probably wait if this
happens again.


Jakub

On Thu, Jan 5, 2023 at 1:45 AM Frank Crawford  wrote:
>
> On Wed, 2023-01-04 at 23:41 +0100, Miro Hrončok wrote:
> > On 02. 12. 22 18:20, Jakub Kadlcik wrote:
> > > Hello folks,
> > >
> > > for a couple of years now, I've been interested in the Fedora
> > > package
> > > review process. Our queue is in hundreds of waiting packages for as
> > > long as I can remember. I believe the situation can be improved.
> > >
> > > Since summer, I did ~40 package reviews to get a better grasp of
> > > the
> > > situation and realized what I want to do.
> > >
> > > I started working on a service [2] that listens to fedora-messaging
> > > and for every new RHBZ review ticket or a new comment with updated
> > > packages, it submits a build in Copr. Thanks to this [1] feature,
> > > Copr
> > > automatically runs the fedora-review tool and generates the
> > > review.txt file. Once the build is finished, my service gets the
> > > message and generates a helpful comment (so far only to STDOUT).
> > >
> > > **Unless there is general disapproval, I am planning to let it post
> > > the comments to Bugzilla.**
> > >
> > > So far the benefit is limited but, it still can immediately tell
> > > the
> > > contributor that their package is broken and fails to build, and
> > > also
> > > saves a reviewer the time of running the fedora-review tool
> > > manually. However, I also implemented support for the fedora-review
> > > tool to generate a JSON output next to the standard review.txt. The
> > > PR
> > > is still pending [2], please review it if you can. Once this is
> > > released, I can parse its contents and generate much helpful
> > > comments
> > > for the contributors.
> > >
> > > The end goal is to let contributors go back and forth against the
> > > CI
> > > to fix the most obvious mistakes and then let the reviewers take
> > > only the final look.
> > >
> > > Hopefully, it will be a better experience for everyone.
> > >
> > >
> > > [1] http://frostyx.cz/posts/running-fedora-review-after-copr-build
> > > [2] https://github.com/FrostyX/fedora-review-service
> > > [3] https://pagure.io/FedoraReview/pull-request/463
> >
> > Jakub, could this service be misbehaving?
> >
> > See https://bugzilla.redhat.com/show_bug.cgi?id=2133080#c19
>
> We also saw the same sort of thing yesterday on an update to a review
> request:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2119983
> >
> > --
> > Miro Hrončok
>
> Regards
> Frank
>
___
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: Orphaned packages looking for new maintainers

[Jakub Kadlcik]

Hello Miro,

> tito frostyx, maxamillion, orphan 3 weeks ago

Taking

On Tue, Dec 20, 2022 at 12:30 AM Emmanuel Seyman  wrote:
>
> * Miro Hrončok [19/12/2022 16:43] :
> >
> > perl-Mail-Procmailorphan   0 weeks 
> > ago
>
> Taken.
>
> Emmanuel
> ___
> 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: Orphaned packages looking for new maintainers

[Jakub Kadlcik]

Hello Miro,

> tito frostyx, maxamillion, orphan 3 weeks ago

Taking

On Tue, Dec 20, 2022 at 12:30 AM Emmanuel Seyman  wrote:
>
> * Miro Hrončok [19/12/2022 16:43] :
> >
> > perl-Mail-Procmailorphan   0 weeks 
> > ago
>
> Taken.
>
> Emmanuel
> ___
> devel mailing list -- de...@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/de...@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Review Service

[Jakub Kadlcik]

I created the Fedora Infra ticket
https://pagure.io/fedora-infrastructure/issue/11028

Jakub

On Sat, Dec 3, 2022 at 1:00 PM Jakub Kadlcik  wrote:
>
> > fedora-review require a lot of manual checks from reviewer (especially
> > licenses). It can't be fully automated.
>
> That's true but my goal isn't to fully automate the process. A person
> will always be required to take the final look and make sure the spec
> is reasonably written and the package is acceptable.
>
> I am looking at it the other way around. I did many reviews where I
> run fedora-review and it printed an issues section and/or some [!]
> checks, so I basically just copy-pasted them into the RHBZ as a
> comment and provided some context about them for the contributor. The
> problem is, that the contributor needed to wait days/weeks/months for
> feedback that CI could have provided immediately.
>
> My hope is also that by saving reviewers the time to point out the
> easy mistakes, we will have time to focus only on the things that, as
> you said, can't be automatized, and therefore cover more tickets as a
> consequence.
>
> Jakub
>
> On Sat, Dec 3, 2022 at 12:25 PM Vitaly Zaitsev via devel
>  wrote:
> >
> > On 02/12/2022 18:20, Jakub Kadlcik wrote:
> > > I started working on a service [2] that listens to fedora-messaging
> > > and for every new RHBZ review ticket or a new comment with updated
> > > packages, it submits a build in Copr. Thanks to this [1] feature, Copr
> > > automatically runs the fedora-review tool and generates the
> > > review.txt file. Once the build is finished, my service gets the
> > > message and generates a helpful comment (so far only to STDOUT).
> >
> > fedora-review require a lot of manual checks from reviewer (especially
> > licenses). It can't be fully automated.
> >
> > But posting this as a template for the reviewer is good idea. +1.
> >
> > --
> > Sincerely,
> >Vitaly Zaitsev (vit...@easycoding.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
> > 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: Fedora Review Service

[Jakub Kadlcik]

> fedora-review require a lot of manual checks from reviewer (especially
> licenses). It can't be fully automated.

That's true but my goal isn't to fully automate the process. A person
will always be required to take the final look and make sure the spec
is reasonably written and the package is acceptable.

I am looking at it the other way around. I did many reviews where I
run fedora-review and it printed an issues section and/or some [!]
checks, so I basically just copy-pasted them into the RHBZ as a
comment and provided some context about them for the contributor. The
problem is, that the contributor needed to wait days/weeks/months for
feedback that CI could have provided immediately.

My hope is also that by saving reviewers the time to point out the
easy mistakes, we will have time to focus only on the things that, as
you said, can't be automatized, and therefore cover more tickets as a
consequence.

Jakub

On Sat, Dec 3, 2022 at 12:25 PM Vitaly Zaitsev via devel
 wrote:
>
> On 02/12/2022 18:20, Jakub Kadlcik wrote:
> > I started working on a service [2] that listens to fedora-messaging
> > and for every new RHBZ review ticket or a new comment with updated
> > packages, it submits a build in Copr. Thanks to this [1] feature, Copr
> > automatically runs the fedora-review tool and generates the
> > review.txt file. Once the build is finished, my service gets the
> > message and generates a helpful comment (so far only to STDOUT).
>
> fedora-review require a lot of manual checks from reviewer (especially
> licenses). It can't be fully automated.
>
> But posting this as a template for the reviewer is good idea. +1.
>
> --
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.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
> 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: Fedora Review Service

[Jakub Kadlcik]

Hello,

> Where does this service currently run? If it's going to be used "in
> anger", perhaps it would be good to put it under fedora-infra control?

Currently running on my laptop. Unpackaged and with hardcoded configuration :-)
But I agree with you. I will soon create a Fedora infra issue and
discuss their requirements and deployment options.

Jakub

On Fri, Dec 2, 2022 at 6:49 PM Adam Williamson
 wrote:
>
> On Fri, 2022-12-02 at 18:20 +0100, Jakub Kadlcik wrote:
> > Hello folks,
> >
> > for a couple of years now, I've been interested in the Fedora package
> > review process. Our queue is in hundreds of waiting packages for as
> > long as I can remember. I believe the situation can be improved.
> >
> > Since summer, I did ~40 package reviews to get a better grasp of the
> > situation and realized what I want to do.
> >
> > I started working on a service [2] that listens to fedora-messaging
> > and for every new RHBZ review ticket or a new comment with updated
> > packages, it submits a build in Copr. Thanks to this [1] feature, Copr
> > automatically runs the fedora-review tool and generates the
> > review.txt file. Once the build is finished, my service gets the
> > message and generates a helpful comment (so far only to STDOUT).
> >
> > **Unless there is general disapproval, I am planning to let it post
> > the comments to Bugzilla.**
>
> This sounds great! Thanks for working on it.
>
> Where does this service currently run? If it's going to be used "in
> anger", perhaps it would be good to put it under fedora-infra control?
> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> 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

Fedora Review Service

[Jakub Kadlcik]

Hello folks,

for a couple of years now, I've been interested in the Fedora package
review process. Our queue is in hundreds of waiting packages for as
long as I can remember. I believe the situation can be improved.

Since summer, I did ~40 package reviews to get a better grasp of the
situation and realized what I want to do.

I started working on a service [2] that listens to fedora-messaging
and for every new RHBZ review ticket or a new comment with updated
packages, it submits a build in Copr. Thanks to this [1] feature, Copr
automatically runs the fedora-review tool and generates the
review.txt file. Once the build is finished, my service gets the
message and generates a helpful comment (so far only to STDOUT).

**Unless there is general disapproval, I am planning to let it post
the comments to Bugzilla.**

So far the benefit is limited but, it still can immediately tell the
contributor that their package is broken and fails to build, and also
saves a reviewer the time of running the fedora-review tool
manually. However, I also implemented support for the fedora-review
tool to generate a JSON output next to the standard review.txt. The PR
is still pending [2], please review it if you can. Once this is
released, I can parse its contents and generate much helpful comments
for the contributors.

The end goal is to let contributors go back and forth against the CI
to fix the most obvious mistakes and then let the reviewers take
only the final look.

Hopefully, it will be a better experience for everyone.


[1] http://frostyx.cz/posts/running-fedora-review-after-copr-build
[2] https://github.com/FrostyX/fedora-review-service
[3] https://pagure.io/FedoraReview/pull-request/463

Jakub
___
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: I made a new Fedora Apps page, do you want it?

[Jakub Kadlcik]

Thank you for the feedback Stan,

> I use a dark theme, and I prefer the gray text only approach of the
> current page to the bright white circles with black text of your
> approach.  I think that is partly to do with the text size difference
> (your text is smaller).

I use light themes so this is something that I didn't consider at all.
Thank you. I will see for myself and make it dark theme friendly.


>  I like the color aesthetics of the current page better, too.

We can try to make some changes, but I thought it would be best to use
the same color scheme as https://getfedora.org/


> Though I would like the viewing window to expand when zoomed in so that it 
> fills the screen.

Cool idea. Will do, thanks.

Jakub

On Thu, Sep 8, 2022 at 2:32 PM stan via devel
 wrote:
>
> On Thu, 8 Sep 2022 12:38:49 +0200
> Jakub Kadlcik  wrote:
>
> > Hello,
> >
> > I am reimplementing the current https://apps.fedoraproject.org
> > page. It is not finished yet, but I wanted to share a demo with you:
> > https://fedora-apps.netlify.app
> >
> > The upstream is here: https://github.com/frostyx/fedora-apps/
> >
> > Do you have any interest to eventually switch to this implementation
> > and sunset the original one?
> >
> > PS: Please don't judge me too harshly for the code quality, I am
> > learning the language. I will refactor once the basic features are
> > done (I know everybody is saying that :D)
>
> I use a dark theme, and I prefer the gray text only approach of the
> current page to the bright white circles with black text of your
> approach.  I think that is partly to do with the text size difference
> (your text is smaller).  I like the color aesthetics of the current
> page better, too. I do like the ability to zoom that you have added, and
> the extra content shown below the initial map.  Though I would like the
> viewing window to expand when zoomed in so that it fills the screen.
>
> I wasn't aware of this before, but it really brings home how many
> aspects there are to Fedora.
> ___
> 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

Fwd: I made a new Fedora Apps page, do you want it?

[Jakub Kadlcik]

Hello,

I am reimplementing the current https://apps.fedoraproject.org
page. It is not finished yet, but I wanted to share a demo with you:
https://fedora-apps.netlify.app

The upstream is here: https://github.com/frostyx/fedora-apps/

Do you have any interest to eventually switch to this implementation
and sunset the original one?

PS: Please don't judge me too harshly for the code quality, I am
learning the language. I will refactor once the basic features are
done (I know everybody is saying that :D)

Jakub
___
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: Package wishlist site?

[Jakub Kadlcik]

Thank you for the feedback. It all makes sense, and I agree with your
points, so I won't put any more effort into this idea. I am also glad,
that this discussion happened and the idea won't be itching my brain
anymore.

Jakub

On Sun, Dec 26, 2021 at 7:31 AM Dan Čermák
 wrote:
>
> Hi Jakube,
>
> Jakub Kadlčík  writes:
>
> > Hello,
> >
> > TL;DR What about a place where people could ask for something to be
> > packaged in Fedora?
>
> As others already commented: I don't think that this is a good
> idea.
>
> Packaging a program for others where you have no real personal
> interest/benefit/buy-in is in my experience not sustainable in the long
> haul, besides nearly no one doing it (probably for that reason). I would
> actually even say that having such a list is harmful to the project as
> it would suggest that someone will eventually package the app, thereby
> more or less guaranteeing disappointment.
>
>
> Cheers,
>
> 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 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

Re: Packager sponsors site

[Jakub Kadlcik]

> I suggest you update the relevant wiki page [1]

Good idea, thank you.
Updated, please take a look.

> I filed your first ticket, about how timezones are displayed.

Thank you, I will revisit the timezones generation.


Jakub

On Mon, Jul 12, 2021 at 5:10 AM Otto Urpelainen  wrote:
>
> Jakub Kadlcik kirjoitti 12.7.2021 klo 3.36:
> > Hello,
> >
> > I am happy to announce that I deployed this little site
> > https://docs.pagure.org/fedora-sponsors/
>
> Thank you for doing this. Finding a sponsor if one of the difficult
> steps in the onboarding process, making is easier is very valuable.
>
> > Please share the site with new packagers if you get a chance.
>
> I suggest you update the relevant wiki page [1] (which is moving to
> docs.fp.o, just pending a pull request approval [2] — I will check any
> pages for recent edits and process them after docs.fp.o move goes live.)
>
> [1]:
> https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
> [2]: https://pagure.io/fedora-docs/docs-fp-o/pull-request/171
>
> > If you would like to know more about the project, see
> > https://github.com/FrostyX/fedora-sponsors
> > Feedback is always appreciated, so don't hesitate to file a new issue or
> > reply here.
>
> I filed your first ticket, about how timezones are displayed.
>
> Otto
> ___
> 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

Packager sponsors site

[Jakub Kadlcik]

Hello,

I am happy to announce that I deployed this little site
https://docs.pagure.org/fedora-sponsors/

Its goal is to help new Fedora packagers find the right sponsor for them
(based on the used programming language, domain of the project, native
language of the packager, etc).

Please share the site with new packagers if you get a chance.

If you would like to know more about the project, see
https://github.com/FrostyX/fedora-sponsors
Feedback is always appreciated, so don't hesitate to file a new issue or
reply here.

Also, if you are a sponsor, please set up your information. Please see
this ticket - https://pagure.io/packager-sponsors/issue/477


Thank you,
Jakub
___
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: Improving Fedora sponsors discoverability

[Jakub Kadlcik]

I am so sorry Kevin, I missed the message for some reason.

> Looks pretty cool. Not sure it would be something for the first cut, or
> later, but it might be nice to have a way to list 'preferred' contact
> method? This might be something we could add to the account system also
> and you could just get it from there? (ie, IRC, Matrix, email, other)

I agree with you, this would be helpful for both sponsors and newcomer
packagers. As you suggest, ideally, we should have this information in
the accounts system (not defined within the sponsors site). Once the
information is available there is no reason why not to display it :-)

I created a ticket for it
https://github.com/fedora-infra/noggin/issues/685

> There are packager groups... could perhaps look at them and get sponsors
> from them? ie, python-sig, graphics-sig, etc?

I originally thought so but then I decided to go with custom
configuration files because I checked SIG memberships of some sponsors
that I know and they never were in the SIG for the thing that I know
they are interested in. Taking you for an example, in your config
https://kevin.fedorapeople.org/sponsor.yaml you have the following
interests - command-line, desktop, mobile, python, and epel but you
are not a member of Desktop SIG, Mobility SIG, and Python SIG.

But I guess we could take the SIG memberships and use them as one of
the sources of configuration (in complement to what we already have).
Does this sound reasonable to you?


Jakub

On Tue, Jun 15, 2021 at 7:43 PM Kevin Fenzi  wrote:
>
> On Fri, Jun 11, 2021 at 05:03:36PM +0200, Jakub Kadlcik wrote:
> > Hello fellow Fedora people,
> >
> > Inspired by @msuchy's Flock 2016 presentation, I
> > would like to tackle one of the topics discussed there - The
> > discoverability of Fedora sponsors for newcomers.
>
> Thanks for taking this on! :)
>
> > I have a website ready to be deployed. If you are interested in the
> > technical details, please see this RFE
> >
> > https://pagure.io/packager-sponsors/issue/470
> >
> > and also the code
> >
> > https://github.com/FrostyX/fedora-sponsors
> >
> > The page design is as simple as possible. You can see some screenshots
> > here.
> >
> > https://pagure.io/packager-sponsors/issue/470#comment-735105
>
> Looks pretty cool. Not sure it would be something for the first cut, or
> later, but it might be nice to have a way to list 'preferred' contact
> method? This might be something we could add to the account system also
> and you could just get it from there? (ie, IRC, Matrix, email, other)
> >
> > A very important feature to me is grouping sponsors by their areas of
> > interests / expertise, and I would like to ask for your help in this
> > matter.
> >
> > At this moment, I have manually defined areas such as Python, C/C++,
> > Haskell, Ruby, Functional programming, Web development, Modularity,
> > etc and manually assigned people to them (the small number, that I
> > personally know that do these kinds of things).
> >
> > Do you have any idea if there is a way to generate such areas and tie
> > people to them based on some already existing information within the
> > Fedora infrastructure?
>
> There are packager groups... could perhaps look at them and get sponsors
> from them? ie, python-sig, graphics-sig, etc?
>
> kevin
> ___
> 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

Improving Fedora sponsors discoverability

[Jakub Kadlcik]

Hello fellow Fedora people,

Inspired by @msuchy's Flock 2016 presentation, I
would like to tackle one of the topics discussed there - The
discoverability of Fedora sponsors for newcomers.

I have a website ready to be deployed. If you are interested in the
technical details, please see this RFE

https://pagure.io/packager-sponsors/issue/470

and also the code

https://github.com/FrostyX/fedora-sponsors

The page design is as simple as possible. You can see some screenshots
here.

https://pagure.io/packager-sponsors/issue/470#comment-735105

A very important feature to me is grouping sponsors by their areas of
interests / expertise, and I would like to ask for your help in this
matter.

At this moment, I have manually defined areas such as Python, C/C++,
Haskell, Ruby, Functional programming, Web development, Modularity,
etc and manually assigned people to them (the small number, that I
personally know that do these kinds of things).

Do you have any idea if there is a way to generate such areas and tie
people to them based on some already existing information within the
Fedora infrastructure?

Otherwise, we will have to stick with manually defined groups, which is
fine with me. But in that case I would like to ask you, what areas of
interest you would like to see. And if you are a Fedora packager
sponsor, in what areas would you like to be listed?


Thank you,
Jakub
___
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: Disabling Fedora 30 chroots in Copr

[Jakub Kadlcik]

Ah, so you meant the F28 and F29 chroots listed here in the build details, e.g.

https://copr.fedorainfracloud.org/coprs/alexpl/molsketch/build/869545/

That is as expected. Possibly we can improve our deletion script to
hide/remove them as well but it is not done yet. The important thing
(from our perspective) is that there is no F28 and F29 data on the
backend

https://copr.fedorainfracloud.org/coprs/alexpl/molsketch/repositories/
https://copr.fedorainfracloud.org/coprs/alexpl/scidavis/repositories/

and therefore we could reclaim its disk space.


Jakub

On Mon, Nov 23, 2020 at 10:58 AM Alexander Ploumistos
 wrote:
>
> Hello again,
>
> Perhaps I'm the one who's misunderstood. Is the fact that F28 and F29 builds 
> are still around unrelated to which chroots are actually there?
> ___
> 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: Disabling Fedora 30 chroots in Copr

[Jakub Kadlcik]

But I can't see any data on the backend, that are older than F30 for
those respective projects:

https://download.copr.fedorainfracloud.org/results/alexpl/molsketch/
https://download.copr.fedorainfracloud.org/results/alexpl/scidavis/

Is that what you mean by

> I noticed that some of my projects still have chroots for even older
> releases, e.g. F28, F29 without the option to remove them.

Or did I misunderstood?


Thank you for the feedback,
Jakub

On Mon, Nov 23, 2020 at 10:04 AM Alexander Ploumistos
 wrote:
>
> On Mon, Nov 23, 2020 at 9:54 AM Jakub Kadlcik  wrote:
> >
> > Hello Alexander,
> > what do those chroots say in their "Remaining time" column, please?
>
> They are not listed at all, see these two:
> https://copr.fedorainfracloud.org/coprs/alexpl/molsketch/repositories/
> https://copr.fedorainfracloud.org/coprs/alexpl/scidavis/repositories/
> ___
> 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: Disabling Fedora 30 chroots in Copr

[Jakub Kadlcik]

Hello Alexander,
what do those chroots say in their "Remaining time" column, please?


Jakub

On Mon, Nov 23, 2020 at 8:34 AM Alexander Ploumistos
 wrote:
>
> Hello Jakub,
>
> I noticed that some of my projects still have chroots for even older
> releases, e.g. F28, F29 without the option to remove them. In another
> instance, only a specific F30 arch shows up among the chroots to be
> removed or extended, while the others architectures are not picked up.
> Is there something I can do to remove them, other than deleting the
> entire build along with every other chroot?
>
> Best regards,
> A.
> ___
> 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: Disabling Fedora 30 chroots in Copr

[Jakub Kadlcik]

Hello again,

the Fedora 30 chroots are disabled for around three months now but so far we
haven't marked the built results as outdated. I did it just now, so
according to Outdated chroots removal policy [1], Copr is
going to preserve existing build results in those chroots for another
180 days and then automatically remove them unless you take an action
and prolong the chroots life span in your projects. Read more about this
feature in the  Copr - Removing outdated chroots blog post [2].

The email notifications for upcoming deletion proved to be unreliable
for some users in the past, therefore we tried to improve this
situation within the latest Copr release [3]. We added some on-page
notifications [4] to let you know if some of your chroots are about to
be deleted soon. We also added a page that shows outdated chroots from
all projects that you are an admin of. This should give you a much
better overview than having to go through all projects and looking
into their settings. It also gives you an option to be proactive, and
add a task to your calendar to prolong the chroots that you care
about, and repeat it once in a few months. It shouldn't take more than
a couple of minutes to complete. Please log-in and see
https://copr.fedorainfracloud.org/user/repositories/


[1] https://docs.pagure.org/copr.copr/copr_outdated_chroots_removal_policy.html
[2] http://frostyx.cz/posts/copr-removing-outdated-chroots
[3] https://docs.pagure.org/copr.copr/release-notes/2020-11-13.html
[4] 
https://docs.pagure.org/copr.copr/release-notes/2020-11-13.html#eol-chroot-repositories

Jakub

On Tue, Aug 18, 2020 at 3:12 PM Jakub Kadlcik  wrote:
>
> Hello,
>
> we have just disabled Fedora 30 chroots in Copr.
>
> According to the Fedora wiki [1], Fedora 30 reached the end of its life
> on 2020-05-26 and therefore we are disabling it in Copr.
>
> That effectively means that from this moment, it is no longer possible
> to submit builds for the following chroots:
>
> - fedora-30-x86_64
> - fedora-30-i386
> - fedora-30-ppc64le
> - fedora-30-aarch64
> - fedora-30-armhfp
>
> [1] https://fedoraproject.org/wiki/End_of_life
>
>
> Jakub
___
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

Disabling Fedora 30 chroots in Copr

[Jakub Kadlcik]

Hello,

we have just disabled Fedora 30 chroots in Copr.

According to the Fedora wiki [1], Fedora 30 reached the end of its life
on 2020-05-26 and therefore we are disabling it in Copr.

That effectively means that from this moment, it is no longer possible
to submit builds for the following chroots:

- fedora-30-x86_64
- fedora-30-i386
- fedora-30-ppc64le
- fedora-30-aarch64
- fedora-30-armhfp

[1] https://fedoraproject.org/wiki/End_of_life


Jakub
___
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

Introducing modulemd-tools

[Jakub Kadlcik]

Hello,

I would like to let you know, that we started a project called
modulemd-tools. It is a collection of small tools for parsing and
generating modulemd YAML files.

At this moment, it provides two scripts - one for generating a
modulemd YAML file based on an existing YUM repository, the other one
is even simpler, and generates a module for all packages in a given
directory. If you would like to see any other use-cases covered,
please let us know.

The project upstream is here

https://github.com/rpm-software-management/modulemd-tools

It is already packaged for Fedora, so just `dnf install
modulemd-tools` to get it.

You can read some additional information in my blog post

http://frostyx.cz/posts/introducing-modulemd-tools


Any feedback is appreciated,
Jakub
___
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

M-x browse-at-remote support for Pagure

[Jakub Kadlcik]

Hello,

recently I've announced on this mailing list, that I implemented
Pagure support for :Gbrowse command in Vim. If you are not familiar
with this feature, it allows you to open a current file or line
selection on a remote hosting platform such as GitHub, GitLab, Pagure,
etc. Then you can easily share the link with your coworkers. If you
are interested, see more information in this blog post.

http://frostyx.cz/posts/vim-gbrowse-support-for-pagure

Since I migrated to Emacs, I was really missing this feature, so I
finally decided to go ahead and implement Pagure support also for the
browse-at-remote package. For more information and a supercool gif
demo, please see my newest blog post.

http://frostyx.cz/posts/emacs-browse-at-pagure

Hopefully, some of you will find it as useful as I do,
Jakub
___
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: Outage: Migration of Copr servers - 2020-02-23 06:00 UTC

[Jakub Kadlcik]

I would like to happily announce, that the migration was successful
and the outage is finally over. Everything should work as expected.

The outage window in which Copr services were unavailable, took
~7 hours and most of it was spent by waiting until the final data
sync finishes, so the migration couldn't happen any faster than that.

On the positive note, we are finally going to add F32 chroots
since the migration was the only blocker for that.

Also, please know that we needed to temporarily disable ppc64le
chroots (as it was previously announced) because at this moment
we don't have access to any builders on that architecture.


Thank you for understanding,
Jakub

On Thu, Feb 20, 2020 at 10:43 AM Pavel Raiskup  wrote:
>
> Another thing good to warn about WRT the movement:
> https://pagure.io/copr/copr/issue/1278
>
> We can not enable Fedora 32 chroots in Fedora Copr at this moment.  It
> would mean several new hundreds of gigabytes of data for us to rsync to
> AWS, and we don't have time for it.
>
> This though means that any build done in Fedora Rawhide is done against
> F33 chroot, and will be later (probably Monday) copied to F32 chroot (for
> those projects that follow fedora branching).  So the builds are going to
> be copied even though they can be incompatible.
>
> It might be a good idea to not build against fedora-rawhide* chroots for now,
> till the next week.
>
> Thanks for understanding,
> Pavel
>
>
> On Wednesday, February 19, 2020 2:13:53 PM CET Jakub Kadlcik wrote:
> > There will be an outage starting at 2020-02-23 06:00 UTC, which will last
> > approximately 7 hours (but can take more if something goes wrong).
> >
> > To convert UTC to your local time, take a look at
> > https://fedoraproject.org/wiki/UTCHowto
> > or run:
> >
> > date -d '2020-02-23 06:00 UTC'
> >
> > Reason for outage:
> >
> > Moving Copr servers from OpenStack to Amazon AWS because OpenStack is
> > going to be shut down soon.
> >
> > Affected Services:
> >
> > copr-frontend - https://copr.fedorainfracloud.org
> > copr-backend - https://copr-be.cloud.fedoraproject.org/
> > copr-distgit
> > copr-keygen
> >
> > Backend repositories should remain available during the outage.
> >
> > Ticket Link:
> >
> > https://pagure.io/fedora-infrastructure/issue/8668
> >
> > Contact Information:
> >
> > Please join #fedora-admin in irc.freenode.net or add comments to the
> > ticket for this outage above.
> >
> >
> > Jakub
> > ___
> > copr-devel mailing list -- copr-de...@lists.fedorahosted.org
> > To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-de...@lists.fedorahosted.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

Outage: Migration of Copr servers - 2020-02-23 06:00 UTC

[Jakub Kadlcik]

There will be an outage starting at 2020-02-23 06:00 UTC, which will last
approximately 7 hours (but can take more if something goes wrong).

To convert UTC to your local time, take a look at
https://fedoraproject.org/wiki/UTCHowto
or run:

date -d '2020-02-23 06:00 UTC'

Reason for outage:

Moving Copr servers from OpenStack to Amazon AWS because OpenStack is
going to be shut down soon.

Affected Services:

copr-frontend - https://copr.fedorainfracloud.org
copr-backend - https://copr-be.cloud.fedoraproject.org/
copr-distgit
copr-keygen

Backend repositories should remain available during the outage.

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/8668

Contact Information:

Please join #fedora-admin in irc.freenode.net or add comments to the
ticket for this outage above.


Jakub
___
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: Disabling Fedora 29 chroots in Copr

[Jakub Kadlcik]

Thank you guys!

Jakub

On Tue, Feb 18, 2020 at 12:42 PM Frantisek Zatloukal
 wrote:
>
> Got one about a day ago :)
>
> On Tue, Feb 18, 2020 at 12:17 PM Jakub Kadlcik  wrote:
>>
>> I would like to ask you, can anyone with non Red Hat email confirm,
>> that they get the notifications? The subject is
>>
>> > [Copr] upcoming deletion of outdated chroots in your projects
>>
>>
>> Thank you,
>> Jakub
>>
>>
>> On Mon, Feb 17, 2020 at 12:21 AM Jakub Kadlcik  wrote:
>> >
>> > Hello,
>> >
>> > we have just disabled Fedora 29 chroots in Copr.
>> >
>> > According to the Fedora wiki [1], Fedora 29 reached the end of its life
>> > on 2019-11-30 and therefore we are disabling it in Copr.
>> >
>> > That effectively means that from this moment, it is no longer possible
>> > to submit builds for the following chroots:
>> >
>> > - fedora-29-x86_64
>> > - fedora-29-i386
>> > - fedora-29-ppc64le
>> > - fedora-29-aarch64
>> >
>> > Additionally, according to Outdated chroots removal policy [2], Copr is
>> > going to preserve existing build results in those chroots for another
>> > 180 days and then automatically remove them unless you take an action
>> > and prolong the chroots life span in your projects. Read more about this
>> > feature in the  Copr - Removing outdated chroots blog post [3].
>> >
>> >
>> > [1] https://fedoraproject.org/wiki/End_of_life
>> > [2] 
>> > https://docs.pagure.org/copr.copr/copr_outdated_chroots_removal_policy.html
>> > [3] http://frostyx.cz/posts/copr-removing-outdated-chroots
>> >
>> > Jakub
>> ___
>> 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
>
>
>
> --
>
> Best regards / S pozdravem,
>
> František Zatloukal
> Quality Engineer
> Red Hat
> ___
> 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: Disabling Fedora 29 chroots in Copr

[Jakub Kadlcik]

I would like to ask you, can anyone with non Red Hat email confirm,
that they get the notifications? The subject is

> [Copr] upcoming deletion of outdated chroots in your projects


Thank you,
Jakub


On Mon, Feb 17, 2020 at 12:21 AM Jakub Kadlcik  wrote:
>
> Hello,
>
> we have just disabled Fedora 29 chroots in Copr.
>
> According to the Fedora wiki [1], Fedora 29 reached the end of its life
> on 2019-11-30 and therefore we are disabling it in Copr.
>
> That effectively means that from this moment, it is no longer possible
> to submit builds for the following chroots:
>
> - fedora-29-x86_64
> - fedora-29-i386
> - fedora-29-ppc64le
> - fedora-29-aarch64
>
> Additionally, according to Outdated chroots removal policy [2], Copr is
> going to preserve existing build results in those chroots for another
> 180 days and then automatically remove them unless you take an action
> and prolong the chroots life span in your projects. Read more about this
> feature in the  Copr - Removing outdated chroots blog post [3].
>
>
> [1] https://fedoraproject.org/wiki/End_of_life
> [2] 
> https://docs.pagure.org/copr.copr/copr_outdated_chroots_removal_policy.html
> [3] http://frostyx.cz/posts/copr-removing-outdated-chroots
>
> Jakub
___
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

Disabling Fedora 29 chroots in Copr

[Jakub Kadlcik]

Hello,

we have just disabled Fedora 29 chroots in Copr.

According to the Fedora wiki [1], Fedora 29 reached the end of its life
on 2019-11-30 and therefore we are disabling it in Copr.

That effectively means that from this moment, it is no longer possible
to submit builds for the following chroots:

- fedora-29-x86_64
- fedora-29-i386
- fedora-29-ppc64le
- fedora-29-aarch64

Additionally, according to Outdated chroots removal policy [2], Copr is
going to preserve existing build results in those chroots for another
180 days and then automatically remove them unless you take an action
and prolong the chroots life span in your projects. Read more about this
feature in the  Copr - Removing outdated chroots blog post [3].


[1] https://fedoraproject.org/wiki/End_of_life
[2] https://docs.pagure.org/copr.copr/copr_outdated_chroots_removal_policy.html
[3] http://frostyx.cz/posts/copr-removing-outdated-chroots

Jakub
___
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: Highlights from the latest Copr release

[Jakub Kadlcik]

Hello Kevin,
thank you for your feedback.

> This is still inherently flawed and unsafe because you have absolutely no
> way of guaranteeing that the notification mail actually reached the
> maintainer, only that it has been sent. E-mail is not a certified delivery
> mechanism.

True, that's why we wanted to have a 180 days preservation period.
The email accounts are not Copr-specific either, they are linked with
FAS. If somebody's mailbox can't be reached by any Fedora service
for half a year, there is something wrong. And I don't think we can do
anything about it.

Though, we are considering implementing some notification icon directly
on the Copr website. Is this something you would like to see?


> The whole concept of opt-out deletion is inherently flawed. It is
> unacceptable to delete user data without explicit confirmation.

I agree, that in the ideal world, it should be that way. But in the meantime,
Copr is not a paid service and has limited resources - mainly disk space.
Not removing any user data, would mean, that by now it wouldn't be possible
to build any package anymore. We would run out of space months ago.
We got promised new storage, but in the meantime, we need to remove
_outdated_ user data, just to keep the service working. Moreover, once
a new fedora is branched from rawhide, we create the chroots with
packages, that was build in rawhide chroots. This eats a lot (I can check
for the numbers) of space immediately after branching.

You can read more about the disk space issues in the original blog post
http://frostyx.cz/posts/copr-removing-outdated-chroots

We needed to figure out, what data we can remove without affecting the
most users. For years, we are removing old build results for packages
whose newer (or same) version was successfully built in the project.
Complying with "It is unacceptable to delete user data without explicit
confirmation", we wouldn't be allowed to do even this. But thanks to
this feature, we were able to not run out of storage for many months,
maybe even years. But lately, this mechanism wasn't sufficient, so we
needed to save disk space somewhere else. Our original idea was to
announce beforehand but then remove all the outdated chroots. Then
we downgraded the idea a little bit and we came with the concept of
notification emails and once an owner doesn't care about the outdated
chroots for his project, removing them.

If you have any other suggestions how to save storage space, let us
know, please. We will look at it.


> And of course, the fix comes too late for the repositories that you folks
> already irremediably destroyed with your deletion rampage. E.g., the latest
> release of Kannolo, Kannolo 27, is now missing one of its default
> repositories and I have no way to fix that (and neither do you, for that
> matter – the only way the problem could be solved would be to allow building
> for Fedora 27 again, then I could simply build the packages again).

What happened, was very unfortunate, by any means intentional, and
we are very sorry about it. A bug slipped into production and broke the
notification command, so any email couldn't be sent. After you reported
the issue, we fixed the bug, added several unit tests to cover any possible
regressions in the future, and updated the code so a chroot that we haven't
sent a notification about, can't be removed. I am aware that it won't un-remove
the data, that were already lost, so it is not that comforting for you, but
unfortunately, we have no way to restore the data.

Temporarily enabling outdated chroots for people who care, to rebuild
their data, wouldn't be that easy too. There is no guarantee that
end of life mock chroots still work.


Jakub


On Mon, Feb 10, 2020 at 1:36 PM Kevin Kofler  wrote:
>
> Pavel Raiskup wrote:
> > - The EOL chroot policy scripts responsible for notifying users about
> >   upcoming removals were fixed, users should now always be notified - and
> >   if for some reason they are not, the EOL chroot will not be removed.
>
> This is still inherently flawed and unsafe because you have absolutely no
> way of guaranteeing that the notification mail actually reached the
> maintainer, only that it has been sent. E-mail is not a certified delivery
> mechanism.
>
> The whole concept of opt-out deletion is inherently flawed. It is
> unacceptable to delete user data without explicit confirmation.
>
> And of course, the fix comes too late for the repositories that you folks
> already irremediably destroyed with your deletion rampage. E.g., the latest
> release of Kannolo, Kannolo 27, is now missing one of its default
> repositories and I have no way to fix that (and neither do you, for that
> matter – the only way the problem could be solved would be to allow building
> for Fedora 27 again, then I could simply build the packages again).
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an 

Re: Copr Build System - review of 2019 and vote for features in 2020

[Jakub Kadlcik]

> For what it's worth, I never got the promised notification for my Coprs.
> The legacy chroots are just gone forever with no warning whatsoever.

I am truly sorry to hear that. I am afraid, that there is no way to recover
those data. Thank you for reporting it though, I have investigated the
issue and did as much as I could to prevent it from happening in the future.

I wrote some unit tests for the feature and more importantly
added a constraint, so we won't remove any chroot, that we haven't sent
a notification email about. I have also found a possible cause of the issue,
so I temporarily disabled the feature.

Tests, fix, and explanation in https://pagure.io/copr/copr/pull-request/1229


Jakub

On Mon, Jan 20, 2020 at 1:09 PM Kevin Kofler  wrote:
>
> Neal Gompa wrote:
> > * building containers, ISOs, disk images
>
> +1 (at least installable live ISOs).
>
> > using kiwi and/or appliance-tools+livecd-tools/lorax
>
> I vote for livecd-creator from livecd-tools, it is the easiest to use
> (and in particular, livecd-creator accepts kickstarts from livemedia-creator
> with little to no changes, whereas the opposite requires many more changes),
> the easiest to do local testing with (because it supports caching
> packages without complicated workarounds), and probably also the easiest to
> integrate into the Copr setup (because it has less stringent setup
> requirements).
>
> (Neal, I know I don't have to explain the rationale to YOU, but the
> other readers should know the rationale. :-) )
>
> > * automatic rebuilds of packages when dependencies change
>
> I am not sure about that one. I would at least like it to be optional
> if implemented (because I would probably not enable it for most of my
> Coprs), and I am concerned about the resource usage.
>
> > The second item would make Rawhide builds so much more useful since
> > they won't just silently remain broken.
>
> Most likely they'll just fail to build instead of silently failing
> to install. ;-) (And then they'll still fail to install because there was
> no successful rebuild.)
>
> Sure, there are cases where a straight rebuild (for a new dependency
> soname) will help, but judging from my experience with Rawhide FTBFSes,
> often, a rebuild with no changes won't even succeed where no soname was
> bumped (and soname bumps typically indicate some API change that makes it
> more likely that the rebuild will fail).
>
> Kevin Kofler
> ___
> 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

Tito 0.6.12 release

[Jakub Kadlcik]

Hello,

I am happy to announce that after two years since the last tito [1] release,
the 0.6.12 is finally out!

See release notes [2]

This very moment, updates were submitted to bodhi [3],
feel free to try them.


[1] https://github.com/dgoodwin/tito/
[2] https://github.com/dgoodwin/tito/releases/tag/tito-0.6.12-1
[3] https://bodhi.fedoraproject.org/updates/FEDORA-2019-5523b63c9c


PS: This was my first release of tito project, so I hope I did
everything correctly.

I would like to thank all contributors,
Jakub
___
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: Temporarily using `best=False' for EPEL-8 builds in Copr

[Jakub Kadlcik]

> These bugs exist in RHEL 8 as well as CentOS 8 based environments. Why do you 
> think that modularity will *ever* work this way?

I don't know whether this question was aimed directly to me, but if so
... I am sorry, I can't help you here. You will probably need to
talk directly to the modularity guys or start a discussion on
devel@lists.fedoraproject.org . I was just trying to apply a known
workaround,
so at least some EPEL-8 building can be done in Copr.


Jakub

On Fri, Oct 11, 2019 at 6:17 AM Leigh Scott  wrote:
>
> Shame on Redhat for using an untested feature 
> https://bugzilla.redhat.com/show_bug.cgi?id=1671683
> ___
> 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

Temporarily using `best=False' for EPEL-8 builds in Copr

[Jakub Kadlcik]

Hello,

currently, there is a problem with building EPEL-8 packages because of
DNF bugs regarding modularity (see RHBZ 1758459).

The only known workaround is to use DNF with `best=False'. Even though
it is something you don't really want to use longterm, we are patching
mock configs epel-8-* chroots, so there can be at least some EPEL-8
building in Copr.

(I am doing the change right now, but it won't affect already
spined-up builders. It will take a while until they get recycled and
use new configuration)

Once the DNF issues get resolved, we are going to drop those patches
and use `best=True` again.

For additional information, please see RHBZ 1756681 and RHBZ 1758467.


Thank you for understanding,
Jakub
___
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

Vim :Gbrowse support for pagure

[Jakub Kadlcik]

Hello,

I don't know how many of you are Vim users and what fraction of those
use plugins. Anyway, there is a great, well-known plugin called
vim-fugitive (by notorious Tim Pope), that provides a lot of cool
features. My favorite one is probably `:Gbrowse` command, which opens
the current file, line or visual selection in your web browser.

Up until now, there was support for GitHub, GitLab, Bitbucket, and
Gitee. The _problem_ is, that a lot of us moved to Pagure ...

... so I wrote a plugin enhancing the :Gbrowse functionality with
Pagure support. Give it a try. If you find it (not) helpful, let me
know!

Code: https://github.com/FrostyX/vim-fugitive-pagure
Blog post: http://frostyx.cz/posts/vim-gbrowse-support-for-pagure


Jakub
___
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

Backend storage clean-up

[Jakub Kadlcik]

Hello,

we have decided that it is a time to go through Copr backend data and
clean it up a little. Due to several bugs forgetting to remove backend
data after removing their records from the database, _temporarily_
backing up some folder here and there, etc, we ended up with a lot of
unknown data, that should have been already deleted.

So, we wrote a script [1] to find data that should be deleted, and we
... haven't deleted it yet. Instead, we put it aside in a case there
were any false-positives by the script. If you want to be extra safe,
I am attaching a list of all of those files, you may check it.

If you find out, that we accidentally want to remove any of your data
that is still being used, please contact us immediately! Otherwise, we
are going to delete it once we are running out of disk space (which
may not take a lot of time)

[1] 
https://pagure.io/copr/copr/blob/master/f/backend/run/copr_print_results_to_delete.py

Thank you for understanding,
Jakub


results-to-delete.xz
Description: application/xz
___
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

Disabling Fedora 28 chroots in Copr

[Jakub Kadlcik]

Hello,

we have just disabled Fedora 28 chroots in Copr.

According to the Fedora wiki [1], Fedora 28 reached the end of its life
on 2019-05-28 and therefore we are disabling it in Copr.

That effectively means that from this moment, it is no longer possible
to submit builds for the following chroots:

- fedora-28-x86_64
- fedora-28-i386
- fedora-28-ppc64le

Additionally, according to Outdated chroots removal policy [2], Copr is
going to preserve existing build results in those chroots for another
180 days and then automatically remove them unless you take an action
and prolong the chroots life span in your projects. Read more about this
feature in the  Copr - Removing outdated chroots blog post [3].


[1] https://fedoraproject.org/wiki/End_of_life
[2] https://docs.pagure.org/copr.copr/copr_outdated_chroots_removal_policy.html
[3] http://frostyx.cz/posts/copr-removing-outdated-chroots

Jakub
___
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: Outage: Upgrade of Copr servers - 2019-07-18 05:00 UTC

[Jakub Kadlcik]

The outage is done, all our servers are now running Fedora 30 and
everything should work again.
We apologize for any inconvenience caused by the outage.

Jakub

On Tue, Jul 16, 2019 at 10:03 PM Jakub Kadlcik  wrote:
>
> There will be an outage starting at 2019-07-18 05:00 UTC, which will last
> approximately 6 hours.
>
> To convert UTC to your local time, take a look at
> https://fedoraproject.org/wiki/UTCHowto
> or run:
>
> date -d '2019-07-18 05:00 UTC'
>
> Reason for outage:
>
> Upgrade of Copr servers to Fedora 30.
>
> Affected Services:
>
> copr-frontend - https://copr.fedorainfracloud.org
> copr-backend - https://copr-be.cloud.fedoraproject.org/
> copr-distgit
> copr-keygen
>
> Ticket Link:
>
> https://pagure.io/fedora-infrastructure/issue/8006
>
> Contact Information:
>
> Please join #fedora-admin in irc.freenode.net or add comments to the
> ticket for this outage above.
___
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

Outage: Upgrade of Copr servers - 2019-07-18 05:00 UTC

[Jakub Kadlcik]

There will be an outage starting at 2019-07-18 05:00 UTC, which will last
approximately 6 hours.

To convert UTC to your local time, take a look at
https://fedoraproject.org/wiki/UTCHowto
or run:

date -d '2019-07-18 05:00 UTC'

Reason for outage:

Upgrade of Copr servers to Fedora 30.

Affected Services:

copr-frontend - https://copr.fedorainfracloud.org
copr-backend - https://copr-be.cloud.fedoraproject.org/
copr-distgit
copr-keygen

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/8006

Contact Information:

Please join #fedora-admin in irc.freenode.net or add comments to the
ticket for this outage above.
___
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

New Copr release

[Jakub Kadlcik]

Hello,
I am happy to announce a new Copr release. This time we have focused mainly
on improving a CI experience and freeing up some disk space, but there is
much more. These are some highlights from this release.


- CLI support for managing permissions
  
  For quite some time, you have asked for a possibility to manage project
  permissions through copr-cli or API. This is now possible, see

  copr-cli request-permissions --help
  copr-cli list-permissions --help
  copr-cli edit-permissions --help


- Temporary projects
  --
  Many people use Copr for CI, which may include creating new projects.
  Those are usually relevant for only a limited time and after that just
  floods up the projects list. Instead of automatizing the deletion of
  old projects all by yourself, try using temporary projects. When creating
  or editing a project, it is possible to set an optional "Delete after days"
  field in the Settings tab. There is also a command line option for this.

  copr-cli create ... --delete-after-days 
  copr-cli modify ... --delete-after-days 


- Automatic removal of old builds
  ---
  Another feature useful for CI, but also for normal projects. Sometimes,
  you don't care about old builds and they just slow working with
  builds table. Avoid this by going to package settings and specifying
  the optional "Max number of builds" parameter. Alternatively, use a
command line.

  copr-cli add-package-* --max-builds 
  copr-cli edit-package-* --max-builds 

This keeps last  builds of this package. Older builds are
automatically deleted.
Note that our general policy for [builds
retention](https://docs.pagure.org/copr.copr/user_documentation.html#how-long-do-you-keep-the-builds)
still applies.


- Pagure CI fixes
  
  Copr is for quite some time listening on fedmsg to react on PR and PUSH
  events from Pagure (both src.fedoraproject.org and pagure.io).
However, previously
  it had several limitations;
  1) only the last commit from "push" or pull-request was analyzed, and thus
  only builds for packages updated by _the last_ commit were triggered, this
  is now fixed and copr analyses complete push/pull-request changes,
  2) only one build per pull-reqeust could ever exist, this artificial rule
  was relaxed and now each PR update (new commit, rebase, ...) triggers
  a new copr build,
  3) the fedmsg listener stopped receiving messages after some time and
  a restart was needed, workaround for this was installed (and we plan to
  move to fedora-messaging which should be more reliable),
  4) there was a small rhbz#1699245 bug.
  As a bonus point, it is now enough to add a pull-request comment with
   `[copr-build]` keyword to manually (re)trigger the CI builds.


- Saving up some disk space
  -
  We are struggling with low disk space and hoping to free some up
  by removing backend and distgit data for old builds. To be specific
- we are now removing:
  * old SRPM import logs
  * old tar files from dist-git look-aside cache
  * SRPM from failed builds older than 14 days


- Turning off notifications for outdated chroots removal
  --
  Talking of disk space, we have recently started sending
  notifications about an upcoming deletion of builds for outdated
  chroots. The notifications suggest that if you still care about
  an outdated distribution, going to project settings and prolong
  the time for which the data is going to be preserved. If you don't
  care about it and don't want to be bothered by emails, you can now
  instantly expire the time and schedule the chroot to be removed.


- Respecting module buildorder
  
  When building a module, the `buildorder` was not respected. This
  issue is now fixed.


- Private data in separate tables
  ---
  We have moved secret/private data about users and projects to
  separate tables. This alone is not very interesting information.
  However, it will allow us to dump our database (except for those
  private tables of course) and share them to the public. This
  will allow you to do custom data analysis and statistics.


Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fwd: Outage: Upgrade of Copr servers - 2019-04-24 17:00 UTC

[Jakub Kadlcik]

There will be an outage starting at 2019-04-24 17:00 UTC, which will last
approximately 4 hours.

To convert UTC to your local time, take a look at
https://fedoraproject.org/wiki/UTCHowto
or run:

date -d '2019-04-24 17:00 UTC'

Reason for outage:

Upgrade of Copr services to the newest version.

Affected Services:

copr-frontend - https://copr.fedorainfracloud.org
copr-backend - https://copr-be.cloud.fedoraproject.org/
copr-distgit
copr-keygen

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/7731

Contact Information:

Please join #fedora-admin in irc.freenode.net or add comments to the
ticket for this outage above.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Copr is going to remove build data from end-of-life chroots

[Jakub Kadlcik]

The initial batch of emails has been sent, so if you use Copr for some time
and have packages built for F27 and lesser, or EPEL5, you should check
your inbox
for a message with the following subject

[Copr] upcoming deletion of outdated chroots in your projects

It was established, that the data will be preserved for 180 days, but
in the blog post
linked above, it was mentioned, that there is an exception for the
first batch. We need to
free some disk space as soon as possible, therefore this time, the preservation
period is by default only 60 days, however with a possibility to
extend it to 180.
The chroots, that will be outdated in the future will be preserved 180
days by default.

Jakub

On Sun, Mar 10, 2019 at 10:58 PM Jakub Kadlcik  wrote:
>
> Hello,
> I would like to let you know, that in the following few days,
> you will start receiving automatized notifications from Copr,
> telling you about deleting repositories for outdated chroots
> and how to proceed if you want to keep them for your projects.
>
> Please read more information about how it is going to work
> and our motivation for doing so, in my blog post.
> http://frostyx.cz/posts/copr-removing-outdated-chroots
>
> Also, please see the "Outdated chroots removal policy"
> in the Copr documentation.
> https://docs.pagure.org/copr.copr/copr_outdated_chroots_removal_policy.html
>
> Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 30 chroots now available in Copr

[Jakub Kadlcik]

Hello,
I've just enabled F30 chroots in Copr.

The projects that have "Follow Fedora branching" enabled, have them
automatically activated as well builds from rawhide forked into them.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Copr is going to remove build data from end-of-life chroots

[Jakub Kadlcik]

Hello,
I would like to let you know, that in the following few days,
you will start receiving automatized notifications from Copr,
telling you about deleting repositories for outdated chroots
and how to proceed if you want to keep them for your projects.

Please read more information about how it is going to work
and our motivation for doing so, in my blog post.
http://frostyx.cz/posts/copr-removing-outdated-chroots

Also, please see the "Outdated chroots removal policy"
in the Copr documentation.
https://docs.pagure.org/copr.copr/copr_outdated_chroots_removal_policy.html

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Highlights from the latest Copr release

[Jakub Kadlcik]

Hello,
recently (on Feb 19) a major Copr update took place. It was announced,
but release notes weren't attached. Because a list of all changes
would be long and boring,
I rather decided to present you some highlights of the release.


- Allow per-package chroot-blacklisting by wildcard patterns
  You can configure chroot blacklist in package settings. It is applied when
  building a package from default source in web UI, copr-cli or via
webhook. This feature
  is useful in cases when you have multiple packages per project and
some of them
  are not supposed to build successfully in all enabled chroots. The
configuration
  supports patterns - for example, to not build a package on EPEL, set
chroot blacklist to  `epel-*`.

- Live SRPM build log for custom method
  When building SRPM via custom method, builder log is now live.

- Modularity fixes
  For quite some time it is possible to build modules in Copr, but
last few months it was not
  possible to properly install them with DNF them on user machines due
to changed
  expectations on a repository. This issue is resolved and it is possible to
  install modules as expected.

- Project forks page
  We have added a small number next to the "Fork this project" button.
It indicates
  how many forks the project has. Click on it to see a list of the
forks and their
  owners.

- Build into sub-repository within the project
  When submitting a build in copr-cli, you can now specify the project in the
  following format `owner/project:reponame` which allows you to build into
  a specific sub-repository within the project. It works the same way as the
  automatized builds from pagure pull requests.
  
https://pagure.io/copr/copr/blob/copr-cli-1.78-1/f/cli/man/copr-cli.1.asciidoc#_217

- API function to wait until builds finish [BZ#1258970]
  https://bugzilla.redhat.com/show_bug.cgi?id=1258970
  There is a common use case among users, to submit a build via API
and then wait
  until its finished, to do some business logic. Yet, we didn't provide any way
  to wait on a build and users had to implement it themselves. Now it
is possible
  to use `wait(...)` function for this. For example:

from copr.v3 import Client
client = Client.create_from_config_file()

build1 = client.build_proxy.create_from_file(...)
build2 = client.build_proxy.create_from_scm(...)
finished = wait([build1, build2])
print("Builds have finished {}sucessfully".format(
"" if succeeded(finished) else "un"))

- API errors with correct status codes
  The Legacy API used just two status codes, 200 for success and 500 for error.
  Because the APIv3 is based on it, this flaw remained to its first
release. Now,
  the APIv3 finally returns the correct status codes.

- Speed up several slow frontend pages
  Including the homepage which loaded slowly mainly because of the recent
  builds box on the right side. The select query for this box was improved
  and the time required for its execution halved.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Web assets in Fedora

[Jakub Kadlcik]

Hello,
I've written a blog post about web assets in Fedora.

Do you bundle third-party libraries/frameworks like jQuery, Bootstrap or
Patternfly into your project and commit them to the git repository?

There is a much better solution how to do it. If you are interested, please
read the article http://frostyx.cz/posts/web-assets-in-fedora


Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org