Re: Fedora Elections - Voting is now open!

[Michal Konecny]

Hi everyone,

could you open a ticket on badges issue tracker [0]? We will look at that.

Michal

[0] - https://github.com/fedora-infra/tahrir/issues

On 20. 05. 24 9:59, Marcin Szydelski wrote:

Also couldn't get the badge.

Pozdrawiam/Best regards,
Marcin Szydelski
http://pl.linkedin.com/in/marcinszydelski
mob. +48 793433899


pon., 20 maj 2024 o 03:18 Jonathan Wright via devel 
 napisał(a):


I noticed the same.

On Sun, May 19, 2024, 20:03 Alexander Ploumistos
 wrote:

Hello,

On Mon, May 20, 2024 at 1:06 AM Aoife Moloney
 wrote:
>
[…]
>  and dont forget to claim your Fedora badge too!

That last bit doesn't seem to be working. Was the "Claim your
I Voted
badge." link always pointing to the URL of the corresponding badge
without any other parameter?
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue


--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue
--
___
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: Login issues to lists.* and src.*? Any outages?

[Michal Konecny]

On 26. 02. 24 18:08, Christopher wrote:

On Mon, Feb 26, 2024 at 6:13 AM Michal Konecny  wrote:
[snip]

It's usually good to wait for some time and try again. If the issue persists 
you can open ticket on
https://pagure.io/fedora-infrastructure/issues

Michal

I did try over the course of a few hours. It wasn't until 3 days later
that I tried again and it worked.
But, filing an issue would have been difficult since I couldn't log in
to pagure.io either, since it uses the same authentication as the
others. I actually did try pagure.io, though I didn't mention it in my
initial email. But, it also didn't work.
--
In this case you can let the admins know about the issue by sending 
e-mail to ad...@fedoraproject.org and somebody will reach to you.

___
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: Login issues to lists.* and src.*? Any outages?

[Michal Konecny]

On 24. 02. 24 12:30, Richard W.M. Jones wrote:

...
So I sometimes have issues logging in.  For example it happened about
5 minutes ago, but the error isn't very interesting:

   Original 
URL:https://id.fedoraproject.org/login/gssapi/negotiate?ipsilon_transaction_id=8d11a868-b8f5-4e65-b48b-a53f592d2cfb
   Redirected URL:https://id.fedoraproject.org/login/pam

   Gateway Timeout

   The gateway did not receive a timely response from the upstream
   server or application.

Is it useful to report these?  Sometimes just retrying works, as
in fact happened when I retried it this time.

Rich.
It's usually good to wait for some time and try again. If the issue 
persists you can open ticket on

https://pagure.io/fedora-infrastructure/issues

Michal

...




--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue


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

Dist-git decoupling investigation finished

[Michal Konecny]

Hi everyone,

We would like to inform you thatAdvanced Reconnaissance Crew (ARC) 
from the CPE 
team finished research into decoupling dist-git from its pagure-related 
dependencies. The finished investigation is available here 



*Disclaimer*: This is only an investigation and it doesn't decide 
anything. The decision itself is being discussed here 



This investigation has come about as part of discussions that arose 
fromIssue #26: DistGit to GitLab Move - initiatives-proposal - 
Pagure.io.


The investigation has the following objectives:

1. Enumerate and write down a description of all the integrations we
   rely on in our current git forge (Pagure)
2. Create a list of integrations to continue after moving to different
   git forge
3. Write a recommendation plan on how we can loosely couple these
   integrations generically with another git forge (make it git forge
   agnostic as possible)
4. Add the list and descriptions of integrations to the right place in
   our documentation

As the investigation is done, we are looking for feedback from 
community. Feel free to reply to this e-mail or if you prefer you can 
reply in discussion thread 
.


On behalf of ARC,
Michal


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

Dist-git decoupling investigation

[Michal Konecny]

Hi everyone,

We would like to inform you that Advanced Reconnaissance Crew (ARC) [0] 
from the CPE team is currently conducting research into decoupling 
dist-git from its pagure-related dependencies.


This investigation has come about as part of discussions that arose from 
https://pagure.io/cpe/initiatives-proposal/issue/26 [1].


The investigation has the following objectives:
1. Enumerate and write down a description of all the integrations we 
rely on in our current git forge (Pagure)
2. Create a list of integrations to continue after moving to different 
git forge
3. Write a recommendation plan on how we can loosely couple these 
integrations generically with another git forge (make it git forge 
agnostic as possible)
4. Add the list and descriptions of integrations to the right place in 
our documentation


This will then inform future design requirements and the next set of 
objectives that looks like this:

* Map API calls that need to remain
* Removing the Pagure from dist-git
* Base git as backend
** What functionality needs to move to dist-git when git is used as base 
backend


You can find a list of existing work items here: 
https://pagure.io/fedora-infra/arc/issues [2]
You can also follow along with the findings on our HackMD: 
https://hackmd.io/@fnF231raRruGKZbPBWKsHQ/SJceJYaxa [3]


On behalf of ARC,
Michal

P.S.: You can also discuss this on discourse: 
https://discussion.fedoraproject.org/t/dist-git-decoupling-investigation/93644 
[4]


[0] https://fedora-arc.readthedocs.io/en/latest/workflow.html
[1] https://pagure.io/cpe/initiatives-proposal/issue/26
[2] https://pagure.io/fedora-infra/arc/issues
[3] https://hackmd.io/@fnF231raRruGKZbPBWKsHQ/SJceJYaxa
[4] 
https://discussion.fedoraproject.org/t/dist-git-decoupling-investigation/93644

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Add a push update mechanism for https://release-monitoring.org/

[Michal Konecny]

We have the packit even recommended in the-new-hotness documentation 
(it's the application responsible for creating tickets in bugzilla when 
release-monitoring.org finds new version).


https://the-new-hotness.readthedocs.io/en/stable/user-guide.html#opening-pull-requests-in-dist-git

Michal

On 28. 08. 23 18:19, Frantisek Lachman wrote:

Hello,

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

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

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

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

František
Packit Product Owner..;)

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


On Mon, Aug 28, 2023 at 3:01 PM Sérgio Basto  wrote:

On Mon, 2023-08-28 at 13:52 +0100, Sérgio Basto wrote:

On Mon, 2023-08-28 at 03:28 +, Ryan Bach via devel wrote:

Faster updates are always as plus.

Should this be under infrastructure list?

Thoughts?


if you got a scratch build completed in a bugzilla for example :

https://bugzilla.redhat.com/show_bug.cgi?id=2231971

you may use my helper script update_from_bugzilla.sh

`fedpkg clone package-foo; cd package-foo ;
../update_from_bugzilla.sh`

forgot to add bugzilla number, so should be

`fedpkg clone package-foo; cd package-foo ; ../update_from_bugzilla.sh
2231971`


Thanks in advance for all the work done to make this distro great.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue

--
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue

--
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
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-scm-requests email

[Michal Konecny]

That's strange, I never noticed this e-mail when doing initial testing 
during first deployment on production.


Michal

On 18. 07. 23 5:35, Kevin Fenzi wrote:

On Tue, Jul 18, 2023 at 02:37:54AM +, Maxwell G wrote:

Hi,

It seems the fedora-scm-requests processor is creating the initial
repository commits with `releng bot ` as the
committer. Does anyone know where this is coming from? Should it be
changed to something @fedoraproject.org?

Very strange. I fixed it in the db... but I am not sure what caused it.

Can look more tomorrow... it looks like it may have been this way since
the automated processing started. ;(

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: Take 1 minute to help with Infra & Releng Team with a decision - closing tomorrow

[Michal Konecny]

The survey is now closed.

We had 67 responses and 67% of those responses are for favor to keep 
gain/trouble labels. So we will keep them, it seems that majority of 
community is happy with them as they are.


Thank you for the responses.

On behalf of I Team,
Michal

On 06. 03. 23 10:22, Michal Konecny wrote:

Hi everyone,

this survey will be closed tomorrow, so you have last day to fill it. 
We will share the results once the survey will be closed. Thanks 
everybody for helping us decide.


On behalf of I Team,
Michal

On 07. 02. 23 16:24, Michal Konecny wrote:

Hi everyone,

it came to Infra & Releng Team (sub-team in CPE that is taking care 
of Fedora Infra, Fedora Release Engineering and CentOS Infra) 
attention that there is a confusion about the labels we are using for 
issues in our trackers. Namely fedora-infrastructure, releng and 
centos-infra. There was even a request to change them to something 
less confusing.


So we want to decide if this is really need to change, so we ask you 
to take this quick survey [0] (this is an anonymous survey, nothing 
is collected by us) to see if the change is really needed or people 
are happy with current labels.


The survey will be closed on 7th March 2023.

On behalf of I Team,
Michal

[0] - https://forms.gle/J2HWDkw1UNuj8HYD8



___
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

Take 1 minute to help with Infra & Releng Team with a decision - closing tomorrow

[Michal Konecny]

Hi everyone,

this survey will be closed tomorrow, so you have last day to fill it. We 
will share the results once the survey will be closed. Thanks everybody 
for helping us decide.


On behalf of I Team,
Michal

On 07. 02. 23 16:24, Michal Konecny wrote:

Hi everyone,

it came to Infra & Releng Team (sub-team in CPE that is taking care of 
Fedora Infra, Fedora Release Engineering and CentOS Infra) attention 
that there is a confusion about the labels we are using for issues in 
our trackers. Namely fedora-infrastructure, releng and centos-infra. 
There was even a request to change them to something less confusing.


So we want to decide if this is really need to change, so we ask you 
to take this quick survey [0] (this is an anonymous survey, nothing is 
collected by us) to see if the change is really needed or people are 
happy with current labels.


The survey will be closed on 7th March 2023.

On behalf of I Team,
Michal

[0] - https://forms.gle/J2HWDkw1UNuj8HYD8

___
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: Take 1 minute to help with Infra & Releng Team with a decision

[Michal Konecny]

On 08. 02. 23 18:54, Chuck Anderson wrote:

On Wed, Feb 08, 2023 at 06:43:02PM +0100, Eike Rathke wrote:

Hi Michal,

On Tuesday, 2023-02-07 16:24:16 +0100, Michal Konecny wrote:


[0] - https://forms.gle/J2HWDkw1UNuj8HYD8

Don't be surprised if you don't get the number of answers you hoped for,
on

a) a Google form
b) that requires a Google account
c) to be logged in

b) and c) are not true.  A private-browsing FF window worked fine for me.
The form was created without the requirements for google account or 
e-mail. It is just a tool in this case.



___
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

Take 1 minute to help with Infra & Releng Team with a decision

[Michal Konecny]

Hi everyone,

it came to Infra & Releng Team (sub-team in CPE that is taking care of 
Fedora Infra, Fedora Release Engineering and CentOS Infra) attention 
that there is a confusion about the labels we are using for issues in 
our trackers. Namely fedora-infrastructure, releng and centos-infra. 
There was even a request to change them to something less confusing.


So we want to decide if this is really need to change, so we ask you to 
take this quick survey [0] (this is an anonymous survey, nothing is 
collected by us) to see if the change is really needed or people are 
happy with current labels.


The survey will be closed on 7th March 2023.

On behalf of I Team,
Michal

[0] - https://forms.gle/J2HWDkw1UNuj8HYD8
___
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: Release monitoring for stable releases only

[Michal Konecny]

This feature is implemented in hotness, which is commenting in Bugzilla.
It's already implemented in dist-git and Pagure as well.
This is now waiting for new version of Pagure to be available in Fedora 
infra,

dist-git with the changes is already available. :-)

You can look at the upcoming monitoring options in the-new-hotness 
documentation [0].


Michal

[0] - https://the-new-hotness.readthedocs.io/en/stable/user-guide.html

On 26. 01. 23 13:38, Jaroslav Skarvada wrote:

On Thu, Jan 26, 2023 at 1:09 PM Neal Gompa  wrote:

On Thu, Jan 26, 2023 at 7:02 AM Jaroslav Skarvada  wrote:

Hi,

it seems Anitya correctly distinguishes stable and pre-release
releases but where to set that I want Fedora bugs only for the stable
releases? IIRC Pagure had a switch for it, but I am unable to find it
on the https://src.fedoraproject.org/rpms/. There is only
"No-Monitoring", "Monitoring", and "Monitoring and scratch builds". It
seems there is no information about it in the docs [1]


You configure it on release-monitoring.org for the upstream project,
not src.fedoraproject.org.

Where? The release-monitoring.org / Anitya correctly marks it as a
pre-release but the bug is still created. There is only a "Pre-release
filter" box, but I think it's a helper if the default regex doesn't
work, which in my case seems to work

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

Anitya [release-monitoring.org] 1.7.0

[Michal Konecny]

Hi everyone,

the new version of Anitya [0] (1.7.0) is deployed on production.

The major change in this version is the migration to Bootstrap 5 [1], 
this means that there is a new design of Anitya.

It also helped to unify the page design in Anitya.

The reason to move to Bootstrap 5 was the change of dependency 
management for CSS and javascript packages. Anitya is now using npm [2] 
for management of those packages and the old version of Bootstrap 
package was not available on npm

anymore.

I hope you will like the new design. :-)

The full changelog can be found in the release page on GitHub [3].

Michal
Mage from release-monitoring.org

[0] - https://release-monitoring.org
[1] - https://getbootstrap.com/
[2] - https://www.npmjs.com/
[3] - https://github.com/fedora-infra/anitya/releases/tag/1.7.0
___
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: Automation of Fedora SCM requests

[Michal Konecny]

I would say that the current way is OK, the bot asks fedora-scm-requests 
admins to validate the requests, because it is marked as exception. 
After being validated it gets created.


Or if there should be an exception for Rust packages, we can add name 
validation and if the name of the package is rust something, we can skip 
the validation process. But this unfortunately let people create any 
repository with name rust with exception set to true without any 
validation and I'm not sure if we want this.


The solution from kevin that the fedpkg request will actually say that 
it's a compat request and provides name of the previous package, it 
could be validated by bot itself and automated. Right now the bot 
doesn't really know if this is a compat package or not, the request 
doesn't have that info.


Michal

On 18. 01. 23 23:13, Kevin Fenzi wrote:

On Wed, Jan 18, 2023 at 12:36:35PM -0600, Michel Alexandre Salim wrote:

Hi Michal,

On Wed, 2023-01-11 at 17:13 +0100, Michal Konecny wrote:

  Hi everyone,
  
  all the remaining issues were solved and the bot is now processing

tickets as it should. I will watch the SCM request repository for
next few days to see if everything is working as it should.
  Thanks for your patience.
  

Where can I direct feature requests? Per
https://pagure.io/releng/fedora-scm-requests/issue/50507 seems like
requesting repos with exceptions (e.g. for Rust compat packages) is
currently not automated.

I'm not sure how we can automate this.

I mean I guess we could just check that the requestor is a packager and
let them create any package name they wish? Or is there some programic
way we can tell it's a compat package and that its correctly named?

Perhaps we could extend fedpkg to ask for and provide more info to the
processing ticket? like name of orig package (check that it exists, etc)
and that the new compat package has a name thats based on it?

Thoughts?

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: Automation of Fedora SCM requests

[Michal Konecny]

Hi Michel,

you can file feature requests in 
https://pagure.io/fedora-infra/toddlers/issues


On behalf of CPE Team,
Michal

On 18. 01. 23 19:36, Michel Alexandre Salim wrote:

Hi Michal,

On Wed, 2023-01-11 at 17:13 +0100, Michal Konecny wrote:

  Hi everyone,
  
  all the remaining issues were solved and the bot is now processing

tickets as it should. I will watch the SCM request repository for
next few days to see if everything is working as it should.
  Thanks for your patience.
  

Where can I direct feature requests? Per
https://pagure.io/releng/fedora-scm-requests/issue/50507 seems like
requesting repos with exceptions (e.g. for Rust compat packages) is
currently not automated.

Thanks,


___
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

Red Hat Bugzilla mail FAS field is now handled correctly by Bugzilla sync scripts

[Michal Konecny]

Hi everybody,

TL;DR; Check if you have correct e-mail in Red Hat Bugzilla Mail field 
in Fedora Accounts [0]. Empty mail is also OK.


the Red Hat Bugzilla Email field in Fedora Accounts [0] was till now 
ignored by most of the apps.


This was changed now with the latest update to toddlers [1], which 
contains most of the syncing scripts that are run automatically in 
Fedora Infra including distgit_bugzilla_sync [2], packager_bugzilla_sync 
[3] and packagers_without_bugzilla [4] scripts. All these scripts are 
using shared methods for working with Fedora Accounts system.


With the addition of scm_request_processor [5] there was a small change 
in how the Fedora Accounts mails are handled in regard to Red Hat 
Bugzilla mail. This change caused it to first look for Red Hat Bugzilla 
Mail and then look at the personnel e-mail associated with the account 
if Bugzilla mail is not set.


This unfortunately caused issues for some users that had Red Hat 
Bugzilla Mail field set incorrectly. I was the one who did the change 
and I actually forgot about it, because it happened at the beginning of 
scm_request_processor development cycle and I didn't know it could have 
that large impact. So I apologize for any issue this could have caused 
for you.


If you are one of the users, who were impacted by this change, you can 
fix it by adding correct Red Hat Bugzilla mail to your Fedora Account. 
You can do this in Settings->Emails in Fedora Accounts page [0].


We will fix the message that is being sent to packagers without Bugzilla 
e-mail to correspond with this change.


On behalf of CPE Team,
Michal

[0] - https://accounts.fedoraproject.org
[1] - https://pagure.io/fedora-infra/toddlers
[2] - 
https://pagure.io/fedora-infra/toddlers/blob/main/f/toddlers/plugins/distgit_bugzilla_sync.py
[3] - 
https://pagure.io/fedora-infra/toddlers/blob/main/f/toddlers/plugins/packager_bugzilla_sync.py
[4] - 
https://pagure.io/fedora-infra/toddlers/blob/main/f/toddlers/plugins/packagers_without_bugzilla.py
[5] - 
https://pagure.io/fedora-infra/toddlers/blob/main/f/toddlers/plugins/scm_request_processor.py

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

Red Hat Bugzilla mail FAS field is now handled correctly by Bugzilla sync scripts

[Michal Konecny]

Hi everybody,

TL;DR; Check if you have correct e-mail in Red Hat Bugzilla Mail field 
in Fedora Accounts [0]. Empty mail is also OK.


the Red Hat Bugzilla Email field in Fedora Accounts [0] was till now 
ignored by most of the apps.


This was changed now with the latest update to toddlers [1], which 
contains most of the syncing scripts that are run automatically in 
Fedora Infra including distgit_bugzilla_sync [2], packager_bugzilla_sync 
[3] and packagers_without_bugzilla [4] scripts. All these scripts are 
using shared methods for working with Fedora Accounts system.


With the addition of scm_request_processor [5] there was a small change 
in how the Fedora Accounts mails are handled in regard to Red Hat 
Bugzilla mail. This change caused it to first look for Red Hat Bugzilla 
Mail and then look at the personnel e-mail associated with the account 
if Bugzilla mail is not set.


This unfortunately caused issues for some users that had Red Hat 
Bugzilla Mail field set incorrectly. I was the one who did the change 
and I actually forgot about it, because it happened at the beginning of 
scm_request_processor development cycle and I didn't know it could have 
that large impact. So I apologize for any issue this could have caused 
for you.


If you are one of the users, who were impacted by this change, you can 
fix it by adding correct Red Hat Bugzilla mail to your Fedora Account. 
You can do this in Settings->Emails in Fedora Accounts page [0].


We will fix the message that is being sent to packagers without Bugzilla 
e-mail to correspond with this change.


On behalf of CPE Team,
Michal

[0] - https://accounts.fedoraproject.org
[1] - https://pagure.io/fedora-infra/toddlers
[2] - 
https://pagure.io/fedora-infra/toddlers/blob/main/f/toddlers/plugins/distgit_bugzilla_sync.py
[3] - 
https://pagure.io/fedora-infra/toddlers/blob/main/f/toddlers/plugins/packager_bugzilla_sync.py
[4] - 
https://pagure.io/fedora-infra/toddlers/blob/main/f/toddlers/plugins/packagers_without_bugzilla.py
[5] - 
https://pagure.io/fedora-infra/toddlers/blob/main/f/toddlers/plugins/scm_request_processor.py

___
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: Automation of Fedora SCM requests

[Michal Konecny]

Hi,

churchyard already responded on this ticket and this is caused by 
webhook that is preventing creating new branches. And he even mentioned 
how we should process it in the SCM Request Processor.


I didn't know there is even something like webhook that could prevent 
pushing new branches and the original script used by release engineering 
didn't cover this case. This needs to be implemented in SCM Request 
Processor.


Michal

On 12. 01. 23 15:27, Jonathan Wright via devel wrote:
Just got the following error: 
https://pagure.io/releng/fedora-scm-requests/issue/50417


I'm pretty sure I've always requested branches as someone with 
"commit" access and never had them rejected.


On Thu, Jan 12, 2023 at 3:30 AM Dominik 'Rathann' Mierzejewski 
 wrote:


On Wednesday, 11 January 2023 at 17:13, Michal Konecny wrote:
> Hi everyone,
>
> all the remaining issues were solved and the bot is now processing
> tickets as it should. I will watch the SCM request repository
for next
> few days to see if everything is working as it should.
> Thanks for your patience.

Thank you Michal and the CPE Team. Automating this part is a very
welcome improvement.

Regards,
Dominik
-- 
Fedora https://getfedora.org  | RPM Fusion http://rpmfusion.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



--
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>

___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue
___
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: Automation of Fedora SCM requests

[Michal Konecny]

Hi everyone,

all the remaining issues were solved and the bot is now processing 
tickets as it should. I will watch the SCM request repository for next 
few days to see if everything is working as it should.

Thanks for your patience.

On behalf of CPE Team,
Michal

On 10. 01. 23 18:29, Michal Konecny wrote:
Most of the issues are resolved now. There is one remaining ticket [0] 
that is returning 500 on branch creation. I will continue 
investigation on this ticket tomorrow.


I'm sorry for the rough start.

On behalf of CPE Team,
Michal

[0] - https://pagure.io/releng/fedora-scm-requests/issue/50370

On 10. 01. 23 13:52, Michal Konecny wrote:

Hi everyone,

after deployment we had some issues with API tokens for 
src.fedorapoject.org and pagure.io. Those issues are now solved.
Only one issue remains and that is missing list of epel9 packages on 
https://infrastructure.fedoraproject.org/repo/json

We are currently working on that.

All the epel9 branch requests will fail right now, we will reprocess 
them once this is fixed.


On behalf of CPE Team,
Michal

On 10. 01. 23 12:26, Michal Konecny wrote:

Hi everyone,

this automation is now in place and new SCM requests will be 
processed automatically. If you find any issue with the automation, 
please report it to toddlers issue tracker [0].


On behalf of CPE Team,
Michal

[0] - https://pagure.io/fedora-infra/toddlers/issues

On 08. 12. 22 11:10, Michal Konecny wrote:

Hello everyone,

for some time CPE (Community Platform Engineering) team is working 
on automating Fedora SCM requests [0]. The automation is currently 
live on staging. You can see the output (closed tickets) in Fedora 
SCM requests staging repo [1].
The automation is done using a plugin in toddlers [2]. We have a 
documentation [3] for the new toddler, if you want to know more 
about it. There is also a ticket [4] tracking this work.


We plan to deploy this in production on *10th January 2023*, after 
that all the Fedora SCM request will be processed automatically and 
it will ping correct people if the manual intervention is needed. 
This will not change anything in user workflow, it will just make 
the job of Fedora Release Engineering Team easier and let them 
focus on other things.


On behalf of CPE Team,
Michal

[0] - https://pagure.io/releng/fedora-scm-requests
[1] - https://stg.pagure.io/releng/fedora-scm-requests
[2] - https://pagure.io/fedora-infra/toddlers
[3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs
[4] - https://pagure.io/releng/issue/9274






___
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: Automation of Fedora SCM requests

[Michal Konecny]

Most of the issues are resolved now. There is one remaining ticket [0] 
that is returning 500 on branch creation. I will continue investigation 
on this ticket tomorrow.


I'm sorry for the rough start.

On behalf of CPE Team,
Michal

[0] - https://pagure.io/releng/fedora-scm-requests/issue/50370

On 10. 01. 23 13:52, Michal Konecny wrote:

Hi everyone,

after deployment we had some issues with API tokens for 
src.fedorapoject.org and pagure.io. Those issues are now solved.
Only one issue remains and that is missing list of epel9 packages on 
https://infrastructure.fedoraproject.org/repo/json

We are currently working on that.

All the epel9 branch requests will fail right now, we will reprocess 
them once this is fixed.


On behalf of CPE Team,
Michal

On 10. 01. 23 12:26, Michal Konecny wrote:

Hi everyone,

this automation is now in place and new SCM requests will be 
processed automatically. If you find any issue with the automation, 
please report it to toddlers issue tracker [0].


On behalf of CPE Team,
Michal

[0] - https://pagure.io/fedora-infra/toddlers/issues

On 08. 12. 22 11:10, Michal Konecny wrote:

Hello everyone,

for some time CPE (Community Platform Engineering) team is working 
on automating Fedora SCM requests [0]. The automation is currently 
live on staging. You can see the output (closed tickets) in Fedora 
SCM requests staging repo [1].
The automation is done using a plugin in toddlers [2]. We have a 
documentation [3] for the new toddler, if you want to know more 
about it. There is also a ticket [4] tracking this work.


We plan to deploy this in production on *10th January 2023*, after 
that all the Fedora SCM request will be processed automatically and 
it will ping correct people if the manual intervention is needed. 
This will not change anything in user workflow, it will just make 
the job of Fedora Release Engineering Team easier and let them focus 
on other things.


On behalf of CPE Team,
Michal

[0] - https://pagure.io/releng/fedora-scm-requests
[1] - https://stg.pagure.io/releng/fedora-scm-requests
[2] - https://pagure.io/fedora-infra/toddlers
[3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs
[4] - https://pagure.io/releng/issue/9274




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

Re: Automation of Fedora SCM requests

[Michal Konecny]

Most of the issues are resolved now. There is one remaining ticket [0] 
that is returning 500 on branch creation. I will continue investigation 
on this ticket tomorrow.


I'm sorry for the rough start.

On behalf of CPE Team,
Michal

[0] - https://pagure.io/releng/fedora-scm-requests/issue/50370

On 10. 01. 23 13:52, Michal Konecny wrote:

Hi everyone,

after deployment we had some issues with API tokens for 
src.fedorapoject.org and pagure.io. Those issues are now solved.
Only one issue remains and that is missing list of epel9 packages on 
https://infrastructure.fedoraproject.org/repo/json

We are currently working on that.

All the epel9 branch requests will fail right now, we will reprocess 
them once this is fixed.


On behalf of CPE Team,
Michal

On 10. 01. 23 12:26, Michal Konecny wrote:

Hi everyone,

this automation is now in place and new SCM requests will be 
processed automatically. If you find any issue with the automation, 
please report it to toddlers issue tracker [0].


On behalf of CPE Team,
Michal

[0] - https://pagure.io/fedora-infra/toddlers/issues

On 08. 12. 22 11:10, Michal Konecny wrote:

Hello everyone,

for some time CPE (Community Platform Engineering) team is working 
on automating Fedora SCM requests [0]. The automation is currently 
live on staging. You can see the output (closed tickets) in Fedora 
SCM requests staging repo [1].
The automation is done using a plugin in toddlers [2]. We have a 
documentation [3] for the new toddler, if you want to know more 
about it. There is also a ticket [4] tracking this work.


We plan to deploy this in production on *10th January 2023*, after 
that all the Fedora SCM request will be processed automatically and 
it will ping correct people if the manual intervention is needed. 
This will not change anything in user workflow, it will just make 
the job of Fedora Release Engineering Team easier and let them focus 
on other things.


On behalf of CPE Team,
Michal

[0] - https://pagure.io/releng/fedora-scm-requests
[1] - https://stg.pagure.io/releng/fedora-scm-requests
[2] - https://pagure.io/fedora-infra/toddlers
[3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs
[4] - https://pagure.io/releng/issue/9274




___
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: Automation of Fedora SCM requests

[Michal Konecny]

The documentation would need to be updated in multiple places, but I 
didn't know about this one. Thanks for sharing.


Michal

On 10. 01. 23 14:08, Richard Shaw wrote:
On Tue, Jan 10, 2023 at 5:26 AM Michal Konecny  
wrote:


Hi everyone,

this automation is now in place and new SCM requests will be
processed automatically. If you find any issue with the
automation, please report it to toddlers issue tracker [0].

On behalf of CPE Team,
Michal

[0] - https://pagure.io/fedora-infra/toddlers/issues


While I'm hopeful I can find this email if needed but it would be 
better if this was documented here (and wherever else appropriate):


https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_New_Contributors/#add_package_to_source_code_management_scm_system_and_set_owner

Thanks,
Richard

___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue
___
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: Automation of Fedora SCM requests

[Michal Konecny]

Hi everyone,

after deployment we had some issues with API tokens for 
src.fedorapoject.org and pagure.io. Those issues are now solved.
Only one issue remains and that is missing list of epel9 packages on 
https://infrastructure.fedoraproject.org/repo/json

We are currently working on that.

All the epel9 branch requests will fail right now, we will reprocess 
them once this is fixed.


On behalf of CPE Team,
Michal

On 10. 01. 23 12:26, Michal Konecny wrote:

Hi everyone,

this automation is now in place and new SCM requests will be processed 
automatically. If you find any issue with the automation, please 
report it to toddlers issue tracker [0].


On behalf of CPE Team,
Michal

[0] - https://pagure.io/fedora-infra/toddlers/issues

On 08. 12. 22 11:10, Michal Konecny wrote:

Hello everyone,

for some time CPE (Community Platform Engineering) team is working on 
automating Fedora SCM requests [0]. The automation is currently live 
on staging. You can see the output (closed tickets) in Fedora SCM 
requests staging repo [1].
The automation is done using a plugin in toddlers [2]. We have a 
documentation [3] for the new toddler, if you want to know more about 
it. There is also a ticket [4] tracking this work.


We plan to deploy this in production on *10th January 2023*, after 
that all the Fedora SCM request will be processed automatically and 
it will ping correct people if the manual intervention is needed. 
This will not change anything in user workflow, it will just make the 
job of Fedora Release Engineering Team easier and let them focus on 
other things.


On behalf of CPE Team,
Michal

[0] - https://pagure.io/releng/fedora-scm-requests
[1] - https://stg.pagure.io/releng/fedora-scm-requests
[2] - https://pagure.io/fedora-infra/toddlers
[3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs
[4] - https://pagure.io/releng/issue/9274


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

Re: Automation of Fedora SCM requests

[Michal Konecny]

Hi everyone,

this automation is now in place and new SCM requests will be processed 
automatically. If you find any issue with the automation, please report 
it to toddlers issue tracker [0].


On behalf of CPE Team,
Michal

[0] - https://pagure.io/fedora-infra/toddlers/issues

On 08. 12. 22 11:10, Michal Konecny wrote:

Hello everyone,

for some time CPE (Community Platform Engineering) team is working on 
automating Fedora SCM requests [0]. The automation is currently live 
on staging. You can see the output (closed tickets) in Fedora SCM 
requests staging repo [1].
The automation is done using a plugin in toddlers [2]. We have a 
documentation [3] for the new toddler, if you want to know more about 
it. There is also a ticket [4] tracking this work.


We plan to deploy this in production on *10th January 2023*, after 
that all the Fedora SCM request will be processed automatically and it 
will ping correct people if the manual intervention is needed. This 
will not change anything in user workflow, it will just make the job 
of Fedora Release Engineering Team easier and let them focus on other 
things.


On behalf of CPE Team,
Michal

[0] - https://pagure.io/releng/fedora-scm-requests
[1] - https://stg.pagure.io/releng/fedora-scm-requests
[2] - https://pagure.io/fedora-infra/toddlers
[3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs
[4] - https://pagure.io/releng/issue/9274
___
devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Automation of Fedora SCM requests

[Michal Konecny]

Hi everyone,

after deployment we had some issues with API tokens for 
src.fedorapoject.org and pagure.io. Those issues are now solved.
Only one issue remains and that is missing list of epel9 packages on 
https://infrastructure.fedoraproject.org/repo/json

We are currently working on that.

All the epel9 branch requests will fail right now, we will reprocess 
them once this is fixed.


On behalf of CPE Team,
Michal

On 10. 01. 23 12:26, Michal Konecny wrote:

Hi everyone,

this automation is now in place and new SCM requests will be processed 
automatically. If you find any issue with the automation, please 
report it to toddlers issue tracker [0].


On behalf of CPE Team,
Michal

[0] - https://pagure.io/fedora-infra/toddlers/issues

On 08. 12. 22 11:10, Michal Konecny wrote:

Hello everyone,

for some time CPE (Community Platform Engineering) team is working on 
automating Fedora SCM requests [0]. The automation is currently live 
on staging. You can see the output (closed tickets) in Fedora SCM 
requests staging repo [1].
The automation is done using a plugin in toddlers [2]. We have a 
documentation [3] for the new toddler, if you want to know more about 
it. There is also a ticket [4] tracking this work.


We plan to deploy this in production on *10th January 2023*, after 
that all the Fedora SCM request will be processed automatically and 
it will ping correct people if the manual intervention is needed. 
This will not change anything in user workflow, it will just make the 
job of Fedora Release Engineering Team easier and let them focus on 
other things.


On behalf of CPE Team,
Michal

[0] - https://pagure.io/releng/fedora-scm-requests
[1] - https://stg.pagure.io/releng/fedora-scm-requests
[2] - https://pagure.io/fedora-infra/toddlers
[3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs
[4] - https://pagure.io/releng/issue/9274


___
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: Automation of Fedora SCM requests

[Michal Konecny]

Hi everyone,

this automation is now in place and new SCM requests will be processed 
automatically. If you find any issue with the automation, please report 
it to toddlers issue tracker [0].


On behalf of CPE Team,
Michal

[0] - https://pagure.io/fedora-infra/toddlers/issues

On 08. 12. 22 11:10, Michal Konecny wrote:

Hello everyone,

for some time CPE (Community Platform Engineering) team is working on 
automating Fedora SCM requests [0]. The automation is currently live 
on staging. You can see the output (closed tickets) in Fedora SCM 
requests staging repo [1].
The automation is done using a plugin in toddlers [2]. We have a 
documentation [3] for the new toddler, if you want to know more about 
it. There is also a ticket [4] tracking this work.


We plan to deploy this in production on *10th January 2023*, after 
that all the Fedora SCM request will be processed automatically and it 
will ping correct people if the manual intervention is needed. This 
will not change anything in user workflow, it will just make the job 
of Fedora Release Engineering Team easier and let them focus on other 
things.


On behalf of CPE Team,
Michal

[0] - https://pagure.io/releng/fedora-scm-requests
[1] - https://stg.pagure.io/releng/fedora-scm-requests
[2] - https://pagure.io/fedora-infra/toddlers
[3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs
[4] - https://pagure.io/releng/issue/9274
___
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: Curious how Upstream Release Monitoring works

[Michal Konecny]

There is a plan to automate that when you request a new package in 
Fedora [0],

but it's still work in progress.

The notification settings are now explained in the-new-hotness 
documentation [1]

with new coming in upcoming release of src.fedoraproject.org.

Michal

[0] - https://pagure.io/releng/issue/10110
[1] - 
https://the-new-hotness.readthedocs.io/en/stable/user-guide.html#notifications-settings


On 14. 12. 22 16:44, Sérgio Basto wrote:

On Wed, 2022-12-14 at 09:36 -0600, Ron Olson wrote:

Hey all-

I’m curious how Upstream Monitoring works; I got a BZ filed that
Swift 5.7.2 is available, which I’m building now, but what surprised
me was how fast the new version was detected and brought to my
attention. Does it use The New Hotness? I set that up awhile ago but
I don’t think it files BZ tickets (and I must not have it set up
correctly as it hasn’t notified me about any releases for the past
year).

To be clear this isn’t a complaint, if anything it’s an awesome
feature and I’m just curious what the mechanism is that makes it
work.


Hi , what package is concrete ?
you need mapping in https://release-monitoring.org/


for example https://release-monitoring.org/project/6221/ and in
src.fedoraproject.org you need set scratch builds
https://src.fedoraproject.org/rpms/smb4k


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

CPE Weekly Update - Week 49 2022

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering) Team.
The report could be found at
https://communityblog.fedoraproject.org/cpe-weekly-update-week-49-2022/.

If you want to receive weekly reports by emails in the future, please
subscribe to either https://communityblog.fedoraproject.org/ or
https://discussion.fedoraproject.org/c/news/commblog/61. We will stop
sending them in 2023.

Regards,
CPE Team
___
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

Automation of Fedora SCM requests

[Michal Konecny]

Hello everyone,

for some time CPE (Community Platform Engineering) team is working on 
automating Fedora SCM requests [0]. The automation is currently live on 
staging. You can see the output (closed tickets) in Fedora SCM requests 
staging repo [1].
The automation is done using a plugin in toddlers [2]. We have a 
documentation [3] for the new toddler, if you want to know more about 
it. There is also a ticket [4] tracking this work.


We plan to deploy this in production on *10th January 2023*, after that 
all the Fedora SCM request will be processed automatically and it will 
ping correct people if the manual intervention is needed. This will not 
change anything in user workflow, it will just make the job of Fedora 
Release Engineering Team easier and let them focus on other things.


On behalf of CPE Team,
Michal

[0] - https://pagure.io/releng/fedora-scm-requests
[1] - https://stg.pagure.io/releng/fedora-scm-requests
[2] - https://pagure.io/fedora-infra/toddlers
[3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs
[4] - https://pagure.io/releng/issue/9274___
devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Automation of Fedora SCM requests

[Michal Konecny]

Hello everyone,

for some time CPE (Community Platform Engineering) team is working on 
automating Fedora SCM requests [0]. The automation is currently live on 
staging. You can see the output (closed tickets) in Fedora SCM requests 
staging repo [1].
The automation is done using a plugin in toddlers [2]. We have a 
documentation [3] for the new toddler, if you want to know more about 
it. There is also a ticket [4] tracking this work.


We plan to deploy this in production on *10th January 2023*, after that 
all the Fedora SCM request will be processed automatically and it will 
ping correct people if the manual intervention is needed. This will not 
change anything in user workflow, it will just make the job of Fedora 
Release Engineering Team easier and let them focus on other things.


On behalf of CPE Team,
Michal

[0] - https://pagure.io/releng/fedora-scm-requests
[1] - https://stg.pagure.io/releng/fedora-scm-requests
[2] - https://pagure.io/fedora-infra/toddlers
[3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs
[4] - https://pagure.io/releng/issue/9274___
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

CPE Weekly Update - Week 42 2022

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering) Team.
The report could be found at https://communityblog.fedoraproject.org/
cpe-weekly-update---week-42-2022/
.

If you want to receive weekly reports by emails in the future, please
subscribe to either https://communityblog.fedoraproject.org/ or
https://discussion.fedoraproject.org/c/news/commblog/61. We will stop
sending them in the future.

Regards,
CPE Team
___
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

CPE Weekly Update - Week 38 2022

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering) Team.
The report could be found at
https://communityblog.fedoraproject.org/cpe-weekly-update---week-38-2022/.

If you want to receive weekly reports by emails in the future, please
subscribe to either https://communityblog.fedoraproject.org/ or
https://discussion.fedoraproject.org/c/news/commblog/61. We will stop
sending them in the future.

Regards,
CPE Team
___
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

CPE Weekly Update - Week 36 2022

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering) Team.
The report could be found at https://communityblog.fedoraproject.org/
cpe-weekly-update---week-36-2022/.

If you want to receive weekly reports by emails in the future, please
subscribe to either https://communityblog.fedoraproject.org/ or
https://discussion.fedoraproject.org/c/news/commblog/61. We will stop
sending them in the future.

Regards,
CPE Team
___
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: CPE Weekly Update - Week 34 2022

[Michal Konecny]

The main reason for this is added infographics, which is better to read 
on blogpost than e-mail. Also the CentOS account works with most of the 
Fedora services, so you shouldn't have issue to subscribe to these services.


Michal

On 27. 08. 22 7:48, Maxwell G via devel wrote:


Aug 26, 2022 7:02:06 AM Michal Konecny :

If you want to receive weekly reports by emails in the future, please 
subscribe to either https://communityblog.fedoraproject.org/ or 
https://discussion.fedoraproject.org/c/news/commblog/61. We will stop 
sending them in the future.
Why is that? I appreciate getting the updates as a clean, plain text 
email that doesn't require clicking external links to read.


Also,  I'd venture that not every CentOS person is interested in the 
Fedora blog or forums.

--
Best,

Maxwell G (@gotmax23)
Pronouns: He/Him/His

___
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

CPE Weekly Update - Week 34 2022

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering) Team.
The report could be found at https://communityblog.fedoraproject.org/
cpe-weekly-update---week-34-2022/.

If you want to receive weekly reports by emails in the future, please
subscribe to either https://communityblog.fedoraproject.org/ or
https://discussion.fedoraproject.org/c/news/commblog/61. We will stop
sending them in the future.

Regards,
CPE Team
___
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

CPE Weekly Update – Week 33 2022

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering) 
Team. If you have any questions or feedback, please respond to this 
report or contact us on #redhat-cpe channel on libera.chat 
(https://libera.chat/).


Week: 15th August - 19th August 2022

If you wish to read this in form of a blog post, check the post on 
Fedora community blog:

https://communityblog.fedoraproject.org/cpe-weekly-update---week-33-2022/

# Highlights of the week

## Infrastructure & Release Engineering
Goal of this Initiative
---
Purpose of this team is to take care of day to day business regarding 
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS 
infrastructure and preparing things for the new Fedora release (mirrors, 
mass branching, new namespaces etc.).
The ARC (which is a subset of the team) investigates possible 
initiatives that CPE might take on.

Link to planning board: https://zlopez.fedorapeople.org/I
Link to docs: https://docs.fedoraproject.org/en-US/infra/

Update
--

### Fedora Infra
* Mass update/reboot cycle this week (stg/nonoutage done, outage later 
today)

* Freeze for f37 beta starts next week


### CentOS Infra including CentOS CI
* Discussion around the CentOS Stream infra hand over
* New tasks for the CI infra migration
* S3 bucket for the Stream CoreOS effort
* Some infra projects moved from gitea to gitlab

### Release Engineering
* Openh264 composes fo f36,37,38 send to cisco
* Package retirement issues after the branching, thanks to human error


## CentOS Stream
Goal of this Initiative
---
This initiative is working on CentOS Stream/Emerging RHEL to make this 
new distribution a reality. The goal of this initiative is to prepare 
the ecosystem for the new CentOS Stream.


Updates
---
* Face to face meeting in Boston.
* Penultimate parts of Module process sync. Between el8 and el9.


## EPEL
Goal of this initiative
---
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special 
Interest Group that creates, maintains, and manages a high quality set 
of additional packages for Enterprise Linux, including, but not limited 
to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), 
Oracle Linux (OL).


EPEL packages are usually based on their Fedora counterparts and will 
never conflict with or replace packages in the base Enterprise Linux 
distributions. EPEL uses much of the same infrastructure as Fedora, 
including buildsystem, bugzilla instance, updates manager, mirror 
manager and more.


Updates
---
* EPEL9 is up to 7339 (+106) packages from 3278 (+71) source packages
* Found the bloaty package was uninstallable because of a libre2 soname 
fix, rebuilding it fixed the issue.



## FMN replacement
Goal of this initiative
---
FMN (Fedora-Messaging-Notification) is a web application allowing users 
to create filters on messages sent to (currently) fedmsg and forward 
these as notifications on to email or IRC.
The goal of the initiative is mainly to add fedora-messaging schemas, 
create a new UI for a better user experience and create a new service to 
triage incoming messages to reduce the current message delivery lag 
problem. Community will profit from speedier notifications based on own 
preferences (IRC, Matrix, Email), unified fedora project to one message 
service and human-readable results in Datagrepper.
Also, CPE tech debt will be significantly reduced by dropping the 
maintenance of fedmsg altogether.


Updates
---
* Frontend
    * Use CoreUI components
    * Set up i18n
    * Initial version of a “New Rule” page
* Authentication integration FE/BE (ongoing)
* Backend: SQLAlchemy integration (ongoing))


Kindest regards,
CPE Team

___
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

CPE Weekly Update - Week 30 2022

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering) 
Team. If you have any questions or feedback, please respond to this 
report or contact us on #redhat-cpe channel on libera.chat 
(https://libera.chat/).


Week: 25th July - 29th July 2022

If you wish to read this in form of a blog post, check the post on 
Fedora community blog:

https://communityblog.fedoraproject.org/cpe-weekly-update-week-30-2022/


# Highlights of the week

## Infrastructure & Release Engineering
Goal of this Initiative
---
Purpose of this team is to take care of day to day business regarding 
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS 
infrastructure and preparing things for the new Fedora release (mirrors, 
mass branching, new namespaces etc.).
The ARC (which is a subset of the team) investigates possible 
initiatives that CPE might take on.

Link to planning board: https://zlopez.fedorapeople.org/I
Link to docs: https://docs.fedoraproject.org/en-US/infra/

Update
--

### Fedora Infra
* New Fedora Media Writer release (mostly translation fixes) 5.0.2
* Rabbitmq cluster instability last week due to both ocp3 and ocp4 
clusters running monitor-gating and them obsoleting each other over and 
over. ;(
* Worked around redhat.com SPF issue by accepting email from redhat.com, 
expanding fedoraproject.org alias and sending it right back out through 
redhat.com mx to deliver.


### CentOS Infra including CentOS CI
* Preparing duffy.ci migration ([now announced for next 
week](https://lists.centos.org/pipermail/ci-users/2022-July/004582.html))


### Release Engineering
* F37 Mass rebuild finished


## CentOS Stream
Goal of this Initiative
---
This initiative is working on CentOS Stream/Emerging RHEL to make this 
new distribution a reality. The goal of this initiative is to prepare 
the ecosystem for the new CentOS Stream.


Updates
---
* Imported c8s modules into the new mbs.
* CentOS Linux 7.9 ISOs are respun


## EPEL
Goal of this initiative
---
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special 
Interest Group that creates, maintains, and manages a high quality set 
of additional packages for Enterprise Linux, including, but not limited 
to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), 
Oracle Linux (OL).


EPEL packages are usually based on their Fedora counterparts and will 
never conflict with or replace packages in the base Enterprise Linux 
distributions. EPEL uses much of the same infrastructure as Fedora, 
including buildsystem, bugzilla instance, updates manager, mirror 
manager and more.


Updates
---
* EPEL9 is up to 6986 (+378) packages from 3137 (+54) source packages
* Backported fix for CVE-2021-21419 to EPEL8's 
[python-eventlet](https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-055f06a731)

* Retired several rawhide branches of EPEL-only packages
* Updated KDE (5.24.6) is available in epel9-next and epel8-next testing.
    * Will not go out to regular epel until RHEL 8.7 and 9.1
* Working on an EPEL survey that will go out in August



## FMN replacement
Goal of this initiative
---
FMN (Fedora-Messaging-Notification) is a web application allowing users 
to create filters on messages sent to (currently) fedmsg and forward 
these as notifications on to email or IRC.
The goal of the initiative is mainly to add fedora-messaging schemas, 
create a new UI for a better user experience and create a new service to 
triage incoming messages to reduce the current message delivery lag 
problem. Community will profit from speedier notifications based on own 
preferences (IRC, Matrix, Email), unified fedora project to one message 
service and human-readable results in Datagrepper.
Also, CPE tech debt will be significantly reduced by dropping the 
maintenance of fedmsg altogether.


Updates
---
* Basic repo structure in place (Python + JS side), more boilerplate 
work ongoing

* Fedora-messaging schemas checkup commenced


Kindest regards,
CPE Team

___
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: HTTP 500 - https://admin.fedoraproject.org/accounts/

[Michal Konecny]

The accounts are now on this URL https://accounts.fedoraproject.org/

Michal

On 28. 07. 22 14:06, Andrew Bauer wrote:

I don't know where to report this, so I'm doing it here.

The backend server that is hosting admin.fedoraproject.org/accounts/ is 
throwing an HTTP 500 SSL handshake error.

This prevents us from using fedora_active_user.py
___
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: Upstream Release Monitoring - bug report

[Michal Konecny]

On 26. 07. 22 21:03, Maxwell G via devel wrote:

On 22/07/26 09:54AM, Kevin Fenzi wrote:

If you want to watch activity on a package you want The little 'watch'
pulldown under The package description. You can set there if you want to
watch bugs, commits, both, etc. If you only wanted to watch koji builds,
you would need to set that in FMN (apps.fedoraproject.org/notifications)

Neither FMN nor the "Watch commits" button on src.fp.o work for me. FMN
just shows a page to set my contact information with no way to create
filters; the "Watch commits" option doesn't work on src.fp.o (i.e. it
doesn't send notifications for new commits) despite working on
pagure.io. I believe the FMN brokenness has something to do with my
account not existing in the old FAS2 instance, but I'm not sure about
the src.fp.o issue. Is it some deliberate configuration difference or a
bug?
You are right. FMN doesn't know users that don't have the account in the 
old FAS2 instance.


About the-new-hotness, the monitoring options are described in it's 
documentation [0]. There are few that aren't supported in src.fp.o yet, 
but the support for them is already implemented in the-new-hotness.


[0] - 
https://the-new-hotness.readthedocs.io/en/stable/user-guide.html#notifications-settings


Michal



___
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: Fedora SCM requests on the weekend

[Michal Konecny]

Last time I checked we were stuck on pagure not emitting any messages on 
staging. I will look into this more this week.


I will try to test on tickets that are on 
https://stg.pagure.io/releng/fedora-scm-requests and if they will be 
processed without issue, I plan to deploy it on production. There will 
be probably some hiccups at the start, hopefully we will solve most of 
them on staging.


Michal

On 11. 07. 22 1:19, Kevin Fenzi wrote:

On Sun, Jul 10, 2022 at 06:34:11PM +0200, Simon de Vlieger wrote:

Would you need any help regarding the automation?

Well, I'm not doing the implementation there, but we can always use
help. ;)

I think the code is all there now, we were wanting to get staging
working to test it before rolling it out.

It's being added as a toddler ( https://pagure.io/fedora-infra/toddlers
) which is basically a framework for things that listen to the message
bus and act on messages or run from time to time to do things.

CCing Michal here for comment on where we can use help here.

kevin
--

On Sat, Jul 9, 2022, at 8:10 PM, Kevin Fenzi wrote:

On Fri, Jul 08, 2022 at 01:02:15PM -, Mukundan Ragavan wrote:

On Sun, Jul 03, 2022 at 12:11:40PM +0200, Fabio Valentini wrote:

That said, until then I can try and run things on weekends.

Is there a formal process to volunteer to hold the keys to the kingdom?

Yes. Basically one of the existing group members nominates someone, and
all the existing group members vote on adding them.

However, at this point we are close to automating it, so not sure it's
worth adding more folks. We could though if it isn't automated soon...

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

Attachments:
* signature.asc

___
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

___
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

CPE Weekly Update – Week 27 2022

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering) 
Team. If you have any questions or feedback, please respond to this 
report or contact us on #redhat-cpe channel on libera.chat 
(https://libera.chat/).


Week: 4th - 7th July 2022

If you wish to read this in form of a blog post, check the post on 
Fedora community blog:

https://communityblog.fedoraproject.org/cpe-weekly-update--week-27-2022/

# Highlights of the week

## Infrastructure & Release Engineering
Goal of this Initiative
---
Purpose of this team is to take care of day to day business regarding 
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS 
infrastructure and preparing things for the new Fedora release (mirrors, 
mass branching, new namespaces etc.).
The ARC (which is a subset of the team) investigates possible 
initiatives that CPE might take on.

Link to docs: https://docs.fedoraproject.org/en-US/infra/

Update
--

### Fedora Infra
* Fas2 is scaled down to 0 instances since last week. Farewell!
* Openshift3 is ready for retirement, will be taking it down later today
* Got toddlers working in staging openshift
* Email thread on infra-sig packages, please contribute
* Koji hubs reinstalled with f36, and z/vm s390x builders upgraded to f36
* Business as usual items


### CentOS Infra including CentOS CI
* Issue with mirrors and dnf being out of sync. PR merged today to fix
* Mirror requests


### Release Engineering
* A few rawhide compose issues, already fixed


## CentOS Stream
Goal of this Initiative
---
This initiative is working on CentOS Stream/Emerging RHEL to make this 
new distribution a reality. The goal of this initiative is to prepare 
the ecosystem for the new CentOS Stream.


Updates
---
* Figured out the root cause of missing module components in CentOS 
Stream 8. Have a script to catch the cases, monitoring it.



## Flask-oidc: oauth2client replacement
Goal of this initiative
---
Flask-oidc is a library used across the Fedora infrastructure and is the 
client for ipsilon for its authentication. flask-oidc uses oauth2client. 
This library is now deprecated and no longer maintained. This will need 
to be replaced with authlib.


Updates:

* Finally happy enough with our code, that we started to port it back 
into the flask-oidc library itself.

* Working on a PR


## EPEL
Goal of this initiative
---
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special 
Interest Group that creates, maintains, and manages a high quality set 
of additional packages for Enterprise Linux, including, but not limited 
to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), 
Oracle Linux (OL).


EPEL packages are usually based on their Fedora counterparts and will 
never conflict with or replace packages in the base Enterprise Linux 
distributions. EPEL uses much of the same infrastructure as Fedora, 
including buildsystem, bugzilla instance, updates manager, mirror 
manager and more.


Updates
---
* EPEL9 is up to 6608 (+92) packages from 2956 (+45) source packages
* resolved "fails to install" bug for 
[xfce4-sensors-plugin-devel](https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-f8140103e3)

* filed various "fails to install" bugs for epel packages
* notable epel9 additions:
    * 
[chromium](https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-002f30f00a)
    * 
[python-paramiko](https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-0bfb2c8312) 
(unblocks multiple other packages)



Kindest regards,
CPE Team
___
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

release-monitoring.org 1.4.0 is now live

[Michal Konecny]

Hi everyone,

today was deployed 1.4.0 version of https://release-monitoring.org.
Here is a highlight of some of the changes:

*Features*
* Add link to AlmaLinux package to distribution mapping
* Add sourceforge (git) backend to retrieve git tags
* Add Python (PEP 440) versioning scheme

*Bug fixes*
* Only include unyanked PyPI versions
* Version Filter not applied on Test Check
* Intermediate versions are skipped while update checking

For full changelog please visit 
https://github.com/fedora-infra/anitya/releases/tag/1.4.0


Regards,
Michal___
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

CPE Weekly Update – Week 24 2022

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering) 
Team. If you have any questions or feedback, please respond to this 
report or contact us on #redhat-cpe channel on libera.chat 
(https://libera.chat/).


Week: 13th - 17th June 2022

If you wish to read this in form of a blog post, check the post on 
Fedora community blog:

https://communityblog.fedoraproject.org/cpe-weekly-update--week-24-2022/

# Highlights of the week

## Infrastructure & Release Engineering
Goal of this Initiative
---
Purpose of this team is to take care of day to day business regarding 
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS 
infrastructure and preparing things for the new Fedora release (mirrors, 
mass branching, new namespaces etc.).
The ARC (which is a subset of the team) investigates possible 
initiatives that CPE might take on.

Link to planning board: https://zlopez.fedorapeople.org/I
Link to docs: https://docs.fedoraproject.org/en-US/infra/

Update
--

### Fedora Infra
* Resultsdb almost moved to ocp4 in prod, just a few parts to finish 
(Thanks Leo!)
* Ocp4 cluster now on our vpn, so all proxies can reach apps (thanks 
darknao!)

* Wiki upgrade looking good in staging, prod to come (thanks ryan!)
* Some more vm’s to f36
* About 50% done moving apps to ocp4.
* Image builder prod move blocked due to firewall issues

### CentOS Infra including CentOS CI
* https://git.centos.org went live last monday
* Trying to resume discussion with RH IT for Stream storage migration
* New CI infra deployment tasks to be ready
* https://lists.centos.org/pipermail/ci-users/2022-June/004547.html

### Release Engineering
* ELN composes were broken over the weekend because of ODCS backend / 
front end version mismatch

* Nodejs-sig removed as the default assignee on a bunch of components in BZ
* we have discovered workflow in bodhi that locks update in a weird 
state more info https://github.com/fedora-infra/bodhi/issues/4566



## CentOS Stream
Goal of this Initiative
---
This initiative is working on CentOS Stream/Emerging RHEL to make this 
new distribution a reality. The goal of this initiative is to prepare 
the ecosystem for the new CentOS Stream.


Updates
---
* We imported all RPMs for modules (CentOS Stream 8) to the shared 
buildsystem

* All sources imported to GitLab (CentOS Stream 8)


## CentOS Duffy CI
Goal of this Initiative
---
Duffy is a system within CentOS CI infrastructure allowing tenants to 
provision and access machines (physical and/or virtual, of different 
architectures and configurations) for the purposes of CI testing. 
Development of Duffy is largely finished, we're currently planning and 
testing deployment scenarios.


Updates
---
* Test and polish `duffy client …` experience
* Docs and CentOS Dojo talk prep


## Package Automation (Packit Service)
Goal of this initiative
---
Automate RPM packaging of infra apps/packages

Updates
---
* Almost finished, only mirrormanager2 remaining from our critical apps 
on Github

* Couple of outliers (fasjson, flask-mod-auth) need downstream repos created
* Datanommer.models manually packaged so datagrepper can be automated
* Noggin now fully automated


## Flask-oidc: oauth2client replacement
Goal of this initiative
---
Flask-oidc is a library used across the Fedora infrastructure and is the 
client for ipsilon for its authentication. flask-oidc uses oauth2client. 
This library is now deprecated and no longer maintained. This will need 
to be replaced with authlib.


Updates:

* Working [poc 
app](https://app-flask-oidc-dev.apps.ocp.stg.fedoraproject.org/oidc/) 
which authenticates against noggin/ipa using authlib and OIDC.

* Working on an upstream PR with the working code now.


## EPEL
Goal of this initiative
---
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special 
Interest Group that creates, maintains, and manages a high quality set 
of additional packages for Enterprise Linux, including, but not limited 
to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), 
Oracle Linux (OL).


EPEL packages are usually based on their Fedora counterparts and will 
never conflict with or replace packages in the base Enterprise Linux 
distributions. EPEL uses much of the same infrastructure as Fedora, 
including buildsystem, bugzilla instance, updates manager, mirror 
manager and more.


Updates
---
* This week we have 6315 (+297)  packages, from 2806 (+76) source packages
* [XFCE now available in 
epel9-testing](https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-5fe886dfa9)

* Removed epel9 packages that were included in rhel9.0
* oniguruma: [backported 
fix](https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-a9236c0113) 
for CVE-2019-13225 (moderate) from rhel8 to epel7
* drbd: 

CPE Weekly Update – Week 23 2022

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering) 
Team. If you have any questions or feedback, please respond to this 
report or contact us on #redhat-cpe channel on libera.chat 
(https://libera.chat/).


Week: 6th - 10th 2022

If you wish to read this in form of a blog post, check the post on 
Fedora community blog:

https://communityblog.fedoraproject.org/cpe-weekly-update--week-23-2022/

# Highlights of the week

## Infrastructure & Release Engineering
Goal of this Initiative
---
Purpose of this team is to take care of day to day business regarding 
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS 
infrastructure and preparing things for the new Fedora release (mirrors, 
mass branching, new namespaces etc.).
The ARC (which is a subset of the team) investigates possible 
initiatives that CPE might take on.

Link to planning board: https://zlopez.fedorapeople.org/I
Link to docs: https://docs.fedoraproject.org/en-US/infra/

Update
--

### Fedora Infra
* Staging instance of release-monitoring.org migrated to OCP4 (fixed 
authentication issue)

* the-new-hotness 1.2.1 released and deployed on production
* Got a bunch of f34 machines reinstalled with f36.
* In the middle of upgrading the wiki (some plugins and theme currently 
broken in staging)

* Image builder prod deployment in process, hit some snags with networks
* Map of critical services is now available in [Fedora Infra 
docs](https://docs.fedoraproject.org/en-US/infra/map_critical_services/)



### CentOS Infra including CentOS CI
* Git.centos.org [scheduled 
migration](https://lists.centos.org/pipermail/centos-devel/2022-June/120391.html) 
(new RHEL8 hosts being prepared)



### Release Engineering
* Fedora 34 is EOL
* Perl side-tag merged into Fedora 37


## CentOS Stream
Goal of this Initiative
---
This initiative is working on CentOS Stream/Emerging RHEL to make this 
new distribution a reality. The goal of this initiative is to prepare 
the ecosystem for the new CentOS Stream.


Updates
---
* Completed scripting for initial import of module RPMs and module-* 
tags.  Initial importing in progress to c9s koji from c8s koji..
* Working on automated scripting to pull new builds so that the c9s koji 
can be automatically updated until we shift to the new koji builder for 
c8s as well as c9s.




## CentOS Duffy CI
Goal of this Initiative
---
Duffy is a system within CentOS CI infrastructure allowing tenants to 
provision and access machines (physical and/or virtual, of different 
architectures and configurations) for the purposes of CI testing. 
Development of Duffy is largely finished, we're currently planning and 
testing deployment scenarios.


Updates
---
* Release 3.0.1, 3.1.0, 3.2.0 (maybe shouldn’t have skipped betas 樂).
* Add client (end user) CLI commands for requesting/retiring/etc. sessions.
* Add API endpoints and corresponding CLI commands for retrieving 
information about configured node pools.
* Fix dependencies to have finer-granular installation options using 
Python package extras (client CLI, task worker, current and legacy web 
API servers).



## Package Automation (Packit Service)
Goal of this initiative
---
Automate RPM packaging of infra apps/packages

Updates
---
* Working on adding packit to datagrepper and noggin
* Fasjson-client in bugzilla review



## Flask-oidc: oauth2client replacement
Goal of this initiative
---
Flask-oidc is a library used across the Fedora infrastructure and is the 
client for ipsilon for its authentication. flask-oidc uses oauth2client. 
This library is now deprecated and no longer maintained. This will need 
to be replaced with authlib.


Updates:

* We now have a very early barebones 
[POC](https://app-flask-oidc-dev.apps.ocp.stg.fedoraproject.org/oidc/) 
in place which makes use of authlib to authenticate over oidc with 
Noggin/IPA.
* Working towards implementing the existing flask-oidc API to retrieve 
user data.



## EPEL
Goal of this initiative
---
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special 
Interest Group that creates, maintains, and manages a high quality set 
of additional packages for Enterprise Linux, including, but not limited 
to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), 
Oracle Linux (OL).


EPEL packages are usually based on their Fedora counterparts and will 
never conflict with or replace packages in the base Enterprise Linux 
distributions. EPEL uses much of the same infrastructure as Fedora, 
including buildsystem, bugzilla instance, updates manager, mirror 
manager and more.


Updates
---
* This week we have 6018 (+155) packages, from 2730 (+58) source packages
* Unused marketing information and links were removed from EPEL docs
* Fedora's backported java_arches macro 

the-new-hotness 1.2.0 released

[Michal Konecny]

Hello everyone,

it's here! Hotness 1.2.0 was released! For those who don't know, 
the-new-hotness is the application that creates the notification for new 
releases on bugzilla for release-monitoring.org. The new version brings 
a lot of new things and I highlight some of them in this e-mail:
* *Support for stable versions only* - now Hotness is supporting the 
settings to only notify about stable versions (only those that are 
recognized as stable by release-monitoring.org)
* *Change in the-new-hotness to work with multiple versions notified at 
once* - Hotness is now able to notify you about multiple versions at 
once. This also adds new monitoring settings, where you can be notified 
about any newly retrieved version by Anitya regardless if it's 
considered newest or not (good for watching for new releases in old 
major versions)


Both of the above changes are for now only in Hotness and PR is waiting 
on pagure [0] and dist-git [1].


* *Add link to monitoring setting to Bugzilla notification* - The 
Bugzilla notification generated by Hotness now contains link to dist-git 
so user can quickly change the monitoring settings if needed. Example on 
staging [2]


To see full changelog, please look at the-new-hotness release [3].

The version is already running in the fedora infra, so you should 
already ripe the fruit of this work. :-)


Michal
Mage from release-monitoring.org

[0] - https://pagure.io/pagure/pull-request/5294
[1] - https://pagure.io/pagure-dist-git/pull-request/151
[2] - https://bugzilla.stage.redhat.com/show_bug.cgi?id=1827715#c81
[3] - https://github.com/fedora-infra/the-new-hotness/releases/tag/1.2.0___
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

CPE Weekly Update – Week 20 2022

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering) 
Team. If you have any questions or feedback, please respond to this 
report or contact us on #redhat-cpe channel on libera.chat 
(https://libera.chat/).


Week: 16th May - 20th May 2022

If you wish to read this in form of a blog post, check the post on 
Fedora community blog:

https://communityblog.fedoraproject.org/cpe-weekly-update---week-20-2022/

# Highlights of the week

## Infrastructure & Release Engineering
Goal of this Initiative
---
Purpose of this team is to take care of day to day business regarding 
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS 
infrastructure and preparing things for the new Fedora release (mirrors, 
mass branching, new namespaces etc.).
The ARC (which is a subset of the team) investigates possible 
initiatives that CPE might take on.

Link to planning board: https://zlopez.fedorapeople.org/I

Update
--

### Fedora Infra
* Fedora Media Writer 5.0.1 is live/done for both windows and macos!
* Email from @redhat.com users to @fedoraproject.org users who use gmail 
is broken due to SPF changes on rh side. [INC2210845 
](https://redhat.service-now.com/surl.do?n=INC2210845)
* Switched to linux-system-roles.nbde_client (automatically unlocking 
encrypted devices via network) role from our home grown incomplete one 
after working thru a dracut bug in RHEL8.3+

* RHEL9 content synced and already switched epel9 to use it.
* Mass update/reboot in progress, outage later today to finish.

### CentOS Infra including CentOS CI
* CentOS Stream storage migration spike (Netapp for nfs/iscsi) (ongoing)
* Duffy fixes and tests (ec2 provisioning working)
* Git.centos.org pagure upgrade/migration (blocked, waiting on internal 
Red Hat Team)
* 9 stream build targets on cbs/koji now consuming centos9s-buildroot 
repositories straight from upstream kojihub for Stream 9 (no latency)

* Business as usual (mirrors, tags)

### Release Engineering
* Archiving older releases
* Updating the EOL release date will be part of the release schedule

### Any Other Bussiness
* All the zuul jobs are now migrated to [centralized 
repository](https://pagure.io/fedora-infra/zuul)



## CentOS Stream
Goal of this Initiative
---
This initiative is working on CentOS Stream/Emerging RHEL to make this 
new distribution a reality. The goal of this initiative is to prepare 
the ecosystem for the new CentOS Stream.


Updates
---
* Changes to the c8s module migration code to automatically filter to 
modules that are released.

* Migration of packages to new c8s infrastructure is moving along.
* Fixing the ELN Everything installer.


## CentOS Duffy CI
Goal of this Initiative
---
Duffy is a system within CentOS CI Infra which allows tenants to 
provision and access bare metal resources of multiple architectures for 
the purposes of CI testing.
We need to add the ability to checkout VMs in CentOS CI in Duffy. We 
have OpenNebula hypervisor available, and have started developing 
playbooks which can be used to create VMs using the OpenNebula API, but 
due to the current state of how Duffy is deployed, we are blocked with 
new dev work to add the VM checkout functionality.


Updates
---
* Deployment: apply database schema migrations
* Test per tenant quotas and provisioning on EC2


## Package Automation (Packit Service)
Goal of this initiative
---
Automate RPM packaging of infra apps/packages

Updates
---
* Mostly business as usual, lots of dependencies
* A fair amount of manual packaging needs to happen for most of our 
applications first

* Reducing a lot of dependency pinning
* Unfortunately packit [doesn’t support 
monorepos](https://github.com/packit/packit/issues/1543) at the moment 
so Bodhi and Datanommer will be blocked until they do. It’s on their 
roadmap.

* scoady pto for ~2 weeks


## Flask-oidc: oauth2client replacement
Goal of this initiative
---
Flask-oidc is a library used across the Fedora infrastructure and is the 
client for ipsilon for its authentication. flask-oidc uses oauth2client. 
This library is now deprecated and no longer maintained. This will need 
to be replaced with authlib.


Updates:

* Starting to 
[implement](https://github.com/fedora-infra/test-auth/blob/authlib_dev/test_auth/flask_oidc.py) 
flask-oidc api using authlib.



## EPEL
Goal of this initiative
---
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special 
Interest Group that creates, maintains, and manages a high quality set 
of additional packages for Enterprise Linux, including, but not limited 
to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), 
Oracle Linux (OL).


EPEL packages are usually based on their Fedora counterparts and will 
never conflict with or replace packages in the base 

CPE Weekly Update – Week 19 2022

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering) 
Team. If you have any questions or feedback, please respond to this 
report or contact us on #redhat-cpe channel on libera.chat 
(https://libera.chat/).


Week: 09th May - 13th May 2022

If you wish to read this in form of a blog post, check the post on 
Fedora community blog:

https://communityblog.fedoraproject.org/cpe-weekly-update---week-19-2022/

# Highlights of the week

## Infrastructure & Release Engineering
Goal of this Initiative
---
Purpose of this team is to take care of day to day business regarding 
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS 
infrastructure and preparing things for the new Fedora release (mirrors, 
mass branching, new namespaces etc.).
The ARC (which is a subset of the team) investigates possible 
initiatives that CPE might take on.

Link to planning board: https://zlopez.fedorapeople.org/I

Update
--

### Fedora Infra
* F34/F35 container builds failing due to 32bit arm ( 
https://bugzilla.redhat.com/show_bug.cgi?id=2077680 )
* git -core change broke koji. Downgraded git and upstream koji already 
has a fix.
* Got a FMW macos build fully signed and notarized! Unfortunately, now 
need to find out how to build it to be able to run on older macos. ;(

* Fedora 36 release went pretty smoothly, we are now out of Freeze
* Business as usual, misc tickets, etc.


### CentOS Infra including CentOS CI
* CentOS Stream storage migration spike (Netapp for nfs/iscsi)
* Duffy fixes and tests
* Investigating hardware issue on CI pool
* Investigating ci.centos.org decommission steps
* Git.centos.org pagure upgrade/migration (blocked, waiting on internal 
Red Hat Team)

* Updated sshd host key signing (sha1 issue for el9 ssh clients)
* Bussiness as usual (mirrors, tags)



### Release Engineering
* F36 is out
* Firmware win binaries signed
* Bussiness as usual - stalled epel packages, package unretirements



## CentOS Stream
Goal of this Initiative
---
This initiative is working on CentOS Stream/Emerging RHEL to make this 
new distribution a reality. The goal of this initiative is to prepare 
the ecosystem for the new CentOS Stream.


Updates
---
* Finished the RPM import for c8s to Stream Koji
* Business as usual otherwise


## CentOS Duffy CI
Goal of this Initiative
---
Duffy is a system within CentOS CI Infra which allows tenants to 
provision and access bare metal resources of multiple architectures for 
the purposes of CI testing.
We need to add the ability to checkout VMs in CentOS CI in Duffy. We 
have OpenNebula hypervisor available, and have started developing 
playbooks which can be used to create VMs using the OpenNebula API, but 
due to the current state of how Duffy is deployed, we are blocked with 
new dev work to add the VM checkout functionality.


Updates
---
* More deployment tests
* Per tenant session lifetimes
* Some bug fixes

## Package Automation (Packit Service)
Goal of this initiative
---
Automate RPM packaging of infra apps/packages

Updates
---
* The team is hitting lots of dependency and sub dependency issues, 
working through them but its slow

* fasjson-client is our first package to be fully automated
    * upstream release -> src.fp.o PR -> koji -> bodhi
* Thanks to Nils, Aurelien and Kevin for their help/advice
* fedora-messaging, datagrepper, fasjson currently being worked on (all 
have deps issues)

* spec files will be staying downstream, packit has a way to facilitate this




## Flask-oidc: oauth2client replacement
Goal of this initiative
---
Flask-oidc is a library used across the Fedora infrastructure and is the 
client for ipsilon for its authentication. flask-oidc uses oauth2client. 
This library is now deprecated and no longer maintained. This will need 
to be replaced with authlib.


Updates:

* Setup dev environment (Work In Progress!)
* Starting to implement flask-oidc api using authlib.


## EPEL
Goal of this initiative
---
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special 
Interest Group that creates, maintains, and manages a high quality set 
of additional packages for Enterprise Linux, including, but not limited 
to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), 
Oracle Linux (OL).


EPEL packages are usually based on their Fedora counterparts and will 
never conflict with or replace packages in the base Enterprise Linux 
distributions. EPEL uses much of the same infrastructure as Fedora, 
including buildsystem, bugzilla instance, updates manager, mirror 
manager and more.


Updates
---
* epel9 up to 2568 source packages (increase of 113 from last week).
* Added rhel+epel-9 mock configs to mock-core-configs.
* Updated slurm in epel7 and epel8 to fix CVE-2022-29500 and CVE-2022-29501.
* 

CPE Weekly Update – Week 17 2022

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering) 
Team. If you have any questions or feedback, please respond to this 
report or contact us on #redhat-cpe channel on libera.chat 
(https://libera.chat/).


Week: 25th April - 29th April 2022

If you wish to read this in form of a blog post, check the post on 
Fedora community blog:

https://communityblog.fedoraproject.org/cpe-weekly-update-week-17-2022/

# Highlights of the week

## Infrastructure & Release Engineering
Goal of this Initiative
---
Purpose of this team is to take care of day to day business regarding 
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS 
infrastructure and preparing things for the new Fedora release (mirrors, 
mass branching, new namespaces etc.).
The ARC (which is a subset of the team) investigates possible 
initiatives that CPE might take on.

Link to planning board: https://zlopez.fedorapeople.org/I

Update
--

### Fedora Infra
* Issues sending email from fedoraproject.org -> redhat.com. Finally got 
tls connection reuse working so we didn’t hit their limits.

* FCOS apps (almost) all moved from ocp3->ocp4 clusters
* Cleaned up after a bodhi bug left rawhide updates in limbo.
* Very close to having resultsdb in ocp4 stg working, just some url 
adjustments left hopefully.
* Anitya and the-new-hotness messaging schemas were moved to separate 
repositories

https://github.com/fedora-infra/the-new-hotness-messages
https://github.com/fedora-infra/anitya-messages

### CentOS Infra including CentOS CI
* Deploying RHEL (like Fedora Infra) in infra is [now 
supported](https://pagure.io/centos-infra/issue/739)
* [Duffy testing/fixes](https://pagure.io/centos-infra/issue/712) still 
ongoing
* Openshift upgrade (fixing jenkins image and [sync 
issue](https://pagure.io/centos-infra/issue/728))

* Bussiness As Usual (new tags/mirrors changes requests)



### Release Engineering
* F36 RC composes 1.1 on friday 1.2 yesterday
* Discussion about where container images live and potential move to quay.io



## CentOS Stream
Goal of this Initiative
---
This initiative is working on CentOS Stream/Emerging RHEL to make this 
new distribution a reality. The goal of this initiative is to prepare 
the ecosystem for the new CentOS Stream.


Updates
---
* Prototyping CI actions for Stream 9 using Duffy system, awaiting 
onboarding from infra

* New compose released
* Upcoming: Reviewing Stream container and image build processes
* Improvements to the CVE checker have been rolled out
* Fedora ELN is being used as a prototype for SHA-1 removal in Fedora



## CentOS Duffy CI
Goal of this Initiative
---
Duffy is a system within CentOS CI Infra which allows tenants to 
provision and access bare metal resources of multiple architectures for 
the purposes of CI testing.
We need to add the ability to checkout VMs in CentOS CI in Duffy. We 
have OpenNebula hypervisor available, and have started developing 
playbooks which can be used to create VMs using the OpenNebula API, but 
due to the current state of how Duffy is deployed, we are blocked with 
new dev work to add the VM checkout functionality.


Updates
---
* Parallelize running provisioning/deprovisioning playbooks
* More testing and minor fixes


## Package Automation (Packit Service)
Goal of this initiative
---
Automate RPM packaging of infra apps/packages

Updates
---
* backlog is stocked with plenty of our apps for the time being, more to 
be added as needed

* Expect emails, lots of emails
* fasjson-client, fedora-messaging and datagrepper currently being worked on
* currently able to build in copr, minus some hiccups
* we are currently looking at the best way to version. what are the 
teams thoughts on moving spec files upstream? it makes everything 
cleaner in packit. thoughts on a postcard please




## Flask-oidc: oauth2client replacement
Goal of this initiative
---
Flask-oidc is a library used across the Fedora infrastructure and is the 
client for ipsilon for its authentication. flask-oidc uses oauth2client. 
This library is now deprecated and no longer maintained. This will need 
to be replaced with authlib.


Updates:

* Currently finding all instances of oauth2client code in the current 
flask-oidc code, mapping functionality to whats available in the authlib 
library.



## EPEL
Goal of this initiative
---
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special 
Interest Group that creates, maintains, and manages a high quality set 
of additional packages for Enterprise Linux, including, but not limited 
to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), 
Oracle Linux (OL).


EPEL packages are usually based on their Fedora counterparts and will 
never conflict with or replace packages in the base Enterprise 

CPE Weekly Update – Week of April 4th – 8th

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering) 
Team. If you have any questions or feedback, please respond to this 
report or contact us on #redhat-cpe channel on libera.chat 
(https://libera.chat/).


If you wish to read this in form of a blog post, check the post on 
Fedora community blog:

https://communityblog.fedoraproject.org/cpe-weekly-update-4th-8th/

# Highlights of the week

## Infrastructure & Release Engineering
Goal of this Initiative
---
Purpose of this team is to take care of day to day business regarding 
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS 
infrastructure and preparing things for the new Fedora release (mirrors, 
mass branching, new namespaces etc.).
The ARC (which is a subset of the team) investigates possible 
initiatives that CPE might take on.

Link to planning board: https://zlopez.fedorapeople.org/I

Update
--

### Fedora Infra
* Started F36 final freeze
* Completed mass update/reboot last week before freeze
* Hit fun koji bug that made it write our signed with mode 600 so it 
didn’t sync. Found and fixed all files and patched koji.
* Had issue with s390x z/vm instances, but they are now back online 
(many thanks dhorak!)
* Internal mail MX changed, blocking emails from fedoraproject.org -> 
redhat.com. Updated to new one and slowly caught up.
* Completed ansible upgrade. Only thing left to fix is fedora-messaging 
callback.



### CentOS Infra including CentOS CI
* Issues with Jenkins openshift sync plugins
* Duffy onboarding with Nils and Pedro
* Bussiness as usual, mirror tickets and koji tag requests ..



### Release Engineering
* F36 releng final freeze
* Retirement of FTI (Fails To Install) packages in F36
* Lots of stalled epel package requests
* F37 changes are landing in our tracker



## CentOS Stream
Goal of this Initiative
---
This initiative is working on CentOS Stream/Emerging RHEL to make this 
new distribution a reality. The goal of this initiative is to prepare 
the ecosystem for the new CentOS Stream.


Updates
---
* Planning completed yesterday, focusing on:
    * 8 + 9 workflow parity
    * Build imports from c8s koji to c9s koji
    * Deploying sync2gitlab service
    * CVE checker service deployment
    * Testing making github actions running in test suite



## CentOS Duffy CI
Goal of this Initiative
---
Duffy is a system within CentOS CI Infra which allows tenants to 
provision and access bare metal resources of multiple architectures for 
the purposes of CI testing.
We need to add the ability to checkout VMs in CentOS CI in Duffy. We 
have OpenNebula hypervisor available, and have started developing 
playbooks which can be used to create VMs using the OpenNebula API, but 
due to the current state of how Duffy is deployed, we are blocked with 
new dev work to add the VM checkout functionality.


Updates
---
* Tests and fixes for cicoclient
* Deployment preparation with Fabian, Pedro and Mark
    * Work on the Ansible role for Duffy
    * Meetings, meetings(, meetings!)


## Bodhi
Goal of this Initiative
---
This initiative is to separate Bodhi into multiple sub packages, fix 
integration and unit tests in CI, fix dependency management and automate 
part of the release process.
Read ARC team findings in detail at: 
https://fedora-arc.readthedocs.io/en/latest/bodhi/index.html


Updates
---
* Bodhi 6.0 will be deployed to production a couple of weeks after the 
Fedora release

* E-mail about what’s new in Bodhi 6.0 sent to devel-announce
* Wrapping up dependency management



## EPEL
Goal of this initiative
---
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special 
Interest Group that creates, maintains, and manages a high quality set 
of additional packages for Enterprise Linux, including, but not limited 
to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), 
Oracle Linux (OL).


EPEL packages are usually based on their Fedora counterparts and will 
never conflict with or replace packages in the base Enterprise Linux 
distributions. EPEL uses much of the same infrastructure as Fedora, 
including buildsystem, bugzilla instance, updates manager, mirror 
manager and more.


Updates
---
* EPEL9 up to 2247 source packages (increase of 33 from last week)
* Rebuilt hwinfo epel8 package to be compatible with unannounced 
libx86emu soname bump

* qt6 on its way to epel9 testing, which will allow more applications
* Other notable new epel9 packages:
    * uwsgi
    * akmods
* Notable mailing list discussions:
    * [Slowing down the stalled request 
process](https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/thread/FBTH7FGVYFVBFJX6QKAPLC6FCV66OY6D/)
    * [Dependency policy for packages in less common RHEL channels 
(HighAvailability, ResilientStorage, 

CPE Weekly Update – Week of March 21st – 25th

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering) 
Team. If you have any questions or feedback, please respond to this 
report or contact us on #redhat-cpe channel on libera.chat 
(https://libera.chat/).


If you wish to read this in form of a blog post, check the post on 
Fedora community blog:

https://communityblog.fedoraproject.org/cpe-weekly-update-week-of-march-21st-25th/

# Highlights of the week

## Infrastructure & Release Engineering
Goal of this Initiative
---
Purpose of this team is to take care of day to day business regarding 
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS 
infrastructure and preparing things for the new Fedora release (mirrors, 
mass branching, new namespaces etc.).
The ARC (which is a subset of the team) investigates possible 
initiatives that CPE might take on.

Link to planning board: https://zlopez.fedorapeople.org/I

Update
--

### Fedora Infra
* Fixed cert generation in ipa staging (needed upgrade run)
* Found problem with proxies that stopped processing, was an apache bug. 
Downgraded back to previous stable version.
* Good progress on testing ansible upgrade. Successfully run playbooks 
with python3.8/ansible-core-2.12.3.

* Usual business.

### CentOS Infra including CentOS CI
* Kicked off work for the ansible [2.9.x => 
5.x](https://pagure.io/centos-infra/issue/496) (good progress so far)
* WIP : new lookaside structure and [building from 
gitlab](https://pagure.io/centos-infra/issue/645) (working but need now 
just last steps like centpkg-minimal)
* Last [centos-repos](https://pagure.io/centos-infra/issue/698) should 
enable the extras-common repo for SIGs (autonomous from 
koji.mbox.centos.org koji builds)

* Multiple 1:1 with phsmoura for infra onboarding
    * Working on [image-build 
issue](https://pagure.io/centos-infra/issue/708) as first ticket

* Bussiness as usual: new koji tags , projects on git.centos.org/rpms

### Release Engineering
* F36 Beta 1.4
* Work on SCM request automation should be finished this week - 
[PR](https://pagure.io/fedora-infra/toddlers/pull-request/93)



## CentOS Stream
Goal of this Initiative
---
This initiative is working on CentOS Stream/Emerging RHEL to make this 
new distribution a reality. The goal of this initiative is to prepare 
the ecosystem for the new CentOS Stream.


Updates
---
* Troubleshooting  service issues
* Build & pushing Extras repos for CentOS Stream 8, once built, tags 
will be available
* Content resolver can now differentiate between warnings (when a 
workload lists packages that don't exist) and failures (actual 
dependency problems).

* DC move went well, all systems operational again


## CentOS Duffy CI
Goal of this Initiative
---
Duffy is a system within CentOS CI Infra which allows tenants to 
provision and access bare metal resources of multiple architectures for 
the purposes of CI testing.
We need to add the ability to checkout VMs in CentOS CI in Duffy. We 
have OpenNebula hypervisor available, and have started developing 
playbooks which can be used to create VMs using the OpenNebula API, but 
due to the current state of how Duffy is deployed, we are blocked with 
new dev work to add the VM checkout functionality.


Updates
---
* Focusing on documentation this week 
https://github.com/CentOS/duffy/issues/253



## Bodhi
Goal of this Initiative
---
This initiative is to separate Bodhi into multiple sub packages, fix 
integration and unit tests in CI, fix dependency management and automate 
part of the release process.
Read ARC team findings in detail at: 
https://fedora-arc.readthedocs.io/en/latest/bodhi/index.html


Updates
---
* Got rid of the DeclEnumType warning with SQLAlchemy 1.4+
* Use namespace packages in accordance with current recommendations 
(avoiding needless .pth files)

* Copy severity when obsoleting a security update
* Updated Vagrant docs
* Dependency management (ongoing)
* Added procedure for pushing the snapshots to staging



## EPEL
Goal of this initiative
---
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special 
Interest Group that creates, maintains, and manages a high quality set 
of additional packages for Enterprise Linux, including, but not limited 
to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), 
Oracle Linux (OL).


EPEL packages are usually based on their Fedora counterparts and will 
never conflict with or replace packages in the base Enterprise Linux 
distributions. EPEL uses much of the same infrastructure as Fedora, 
including buildsystem, bugzilla instance, updates manager, mirror 
manager and more.


Updates
---
* EPEL9 up to 2187 source packages (increase of 39 from last week)
* Notable EPEL9 packages now available:
    * [KDE 

CPE Weekly Update – Week of February 28th – March 3rd

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering) 
Team. If you have any questions or feedback, please respond to this 
report or contact us on #redhat-cpe channel on libera.chat 
(https://libera.chat/).


If you wish to read this in form of a blog post, check the post on 
Fedora community blog:

https://communityblog.fedoraproject.org/cpe-weekly-update-week-of-february-28th-march-3rd/

# Highlights of the week

## Infrastructure & Release Engineering
Goal of this Initiative
---
Purpose of this team is to take care of day to day business regarding 
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS 
infrastructure and preparing things for the new Fedora release (mirrors, 
mass branching, new namespaces etc.).
The ARC (which is a subset of the team) investigates possible 
initiatives that CPE might take on.


Update
--

### Fedora Infra
* One new power9 online in iad2, second one needs hands on today.
* Almost all bugzilla auth changes made, still need some changes to 
toddlers (ongoing)
* Container builds broken again in an odd way ( 
https://pagure.io/releng/issue/10658)
* Discussion on fedoraplanet.org on infrastructure list, please chime in 
if you have thoughts about it.


### CentOS Infra including CentOS CI
* Migration of Pagure to new CentOS CI in progress
* Openssl3 [late 
change](https://gitlab.com/redhat/centos-stream/rpms/openssl/-/commit/78fb78d30755ae18fdaef28ef392f4e67c662ff6) 
in EL9 impacting SIGs and gpg keys


### Release Engineering
* Work on SCM request automation in progress - 
[PR](https://pagure.io/fedora-infra/toddlers/pull-request/93)

* Container builds failing on armhfp
* Bussiness as usual


## CentOS Stream
Goal of this Initiative
---
This initiative is working on CentOS Stream/Emerging RHEL to make this 
new distribution a reality. The goal of this initiative is to prepare 
the ecosystem for the new CentOS Stream.


Updates
---
* Investigating compose QA improvements both in the t-functional suite 
and changes we may want to implement later in the project.

* Developing sync2gitlab service for 8, 9 workflow alignment
* Business as usual activities around CentOS Linux 7
* Work continuing on content resolvers maintainer pages also


## CentOS Duffy CI
Goal of this Initiative
---
Duffy is a system within CentOS CI Infra which allows tenants to 
provision and access bare metal resources of multiple architectures for 
the purposes of CI testing.
We need to add the ability to checkout VMs in CentOS CI in Duffy. We 
have OpenNebula hypervisor available, and have started developing 
playbooks which can be used to create VMs using the OpenNebula API, but 
due to the current state of how Duffy is deployed, we are blocked with 
new dev work to add the VM checkout functionality.


Updates
---
* Demo/Status call
* Deployment to staging (ongoing)
* Documentation (ongoing)
* Expiring sessions (ongoing)


## Image builder for Fedora IoT
Goal of this Initiative
---
Integration of Image builder as a service with Fedora infra to allow 
Fedora IoT migrate their pipeline to Fedora infra.


Updates
---
* No updates


## Bodhi
Goal of this Initiative
---
This initiative is to separate Bodhi into multiple sub packages, fix 
integration and unit tests in CI, fix dependency management and automate 
part of the release process.
Read ARC team findings in detail at: 
https://fedora-arc.readthedocs.io/en/latest/bodhi/index.html


Updates
---
* No updates


## EPEL
Goal of this initiative
---
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special 
Interest Group that creates, maintains, and manages a high quality set 
of additional packages for Enterprise Linux, including, but not limited 
to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), 
Oracle Linux (OL).


EPEL packages are usually based on their Fedora counterparts and will 
never conflict with or replace packages in the base Enterprise Linux 
distributions. EPEL uses much of the same infrastructure as Fedora, 
including buildsystem, bugzilla instance, updates manager, mirror 
manager and more.


Updates
---
* EPEL9 up to 2059 source packages (increase of 71 from last week)
* EPEL9 buildroot has switched to a snapshot of the CentOS Stream 9 
mirror, to avoid building against any 9.1 changes prior to the RHEL 9.0 GA
* [EPEL Office 
Hours](https://communityblog.fedoraproject.org/epel-office-hours/) were 
yestarday at 1700 UTC
* epel-release (and epel-next-release) now available in CentOS Stream 9 
Extras repo



Kindest regards,
CPE Team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

Re: VERY late notification emails

[Michal Konecny]

On 28. 02. 22 18:24, Kevin Fenzi wrote:

On Mon, Feb 28, 2022 at 07:45:27AM -0600, Richard Shaw wrote:

I almost wrote this a week ago but decided not to as it's been recently
discussed but this is really annoying. 6 days later is more than useless.

Previously it was blamed, at least partially, on the mass rebuild, but
clearly that should no longer be an issue by now?

Well, I noted a number of reasons for it... one of them was that it
sometimes crashes, but appears to be processing. This happened a few
days ago and it was just restarted this morning. ;(


I know I can turn them off, but I actually LIKE the messages if they were
delivered promptly.

Is there really nothing we can do about this?

No, there's things we can do and are trying to do. ;)

But of course more help welcome!

We have a python3 port of it nearly ready to go, but I think it's
CI/tests are not working, and we want to make sure those all work before
we deploy it. I'll see if I can get more exact status...
CI is now working and the tests are passing. But I wasn't able to 
actually found out how the new version FMN should be released.


Michal


There's also been a lot of talk about re-writing it. Ryan just posted
recently asking for folks use cases and pain points for that.

I'll see about making it restart every day perhaps to make sure it's
actually processing.

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

CPE Weekly Update – Week of February 7th – 11th

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering)
Team. If you have any questions or feedback, please respond to this
report or contact us on #redhat-cpe channel on libera.chat
(https://libera.chat/).

If you wish to read this in form of a blog post, check the post on
Fedora community blog:
https://communityblog.fedoraproject.org/cpe-weekly-update-week-of-february-7th-11th/

# Highlights of the week

## Infrastructure & Release Engineering
Goal of this Initiative
---
Purpose of this team is to take care of day to day business regarding
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS
infrastructure and preparing things for the new Fedora release
(mirrors, mass branching, new namespaces etc.). The ARC (which is a
subset of the team) investigates possible initiatives that CPE might
take on.

Update
--

### Fedora Infra
* Got koji issues sorted and things back on track
* Worked with Fedora CoreOS folks on bringing up a ppc64le builder, 
which exposed a virt issue we have. Will be installing a power9 box with 
Fedora 35 to test if it fixes it.
* Got more ocp4 workers added, upgraded clusters a few times without 
incident
* First live prod app on ocp4 
([blockerbugs](https://qa.fedoraproject.org/blockerbugs/))

* Outage Friday caused by disk space issue on proxies. ;(
* 2 10TB iscsi volumes setup on fedora iad2 netapp for CentOS folks.
* Fedimg is broken apparently, caused ci issues. Still need to find a 
fix to it. ( https://pagure.io/fedora-infrastructure/issue/10532 )



### CentOS Infra including CentOS CI
* Still storage/hardware issues to work on
* [Dell server](https://pagure.io/centos-infra/issue/649) for 
iscsi/netapp usage

* CentOS [backup server](https://pagure.io/centos-infra/issue/618)
* https://debuginfod.centos.org should be 
[live/announced](https://lists.centos.org/pipermail/centos-devel/2022-February/120208.html) 
(content for CentOS Stream 8 and 9 and SIGs packages)

* Bussiness as usual


### Release Engineering
* Branching of F36
* Rawhide nightlies are enabled again
* F37 builds are being signed with F37 key
* We have a Fedora 36 branched compose done already
* Started work on [automation of scm 
requests](https://pagure.io/releng/issue/9274)


## CentOS Stream
Goal of this Initiative
---
This initiative is working on CentOS Stream/Emerging RHEL to make this
new distribution a reality. The goal of this initiative is to prepare
the ecosystem for the new CentOS Stream.

Updates
---
* February planning done
    * Adding centpkg to EPEL
    * Continuing aligning c8s + c9s workflows with an optimum delivery 
date now agreed

    * Content Resolver upgrades continuing with maintainer page being added




## CentOS Duffy CI
Goal of this Initiative
---
Duffy is a system within CentOS CI Infra which allows tenants to 
provision and

access bare metal resources of multiple architectures for the purposes of
CI testing.
We need to add the ability to checkout VMs in CentOS CI in Duffy. We have
OpenNebula hypervisor available, and have started developing playbooks which
can be used to create VMs using the OpenNebula API, but due to the 
current state

of how Duffy is deployed, we are blocked with new dev work to add the
VM checkout functionality.

Updates
---
* Legacy API meta client merged
* Provisioning/Deprovisioning implemented (in review)
* Outstanding: integration tests & loose ends



## Image builder for Fedora IoT
Goal of this Initiative
---
Integration of Image builder as a service with Fedora infra to allow 
Fedora IoT migrate their pipeline to Fedora infra.


Updates
---
* local dev environment successfully deployed
* koji in containers, mocked oidc auth, builder in containers, and 
osbuild-compose running as a service
* We can run a full koji build using the image-builder plugins to make a 
successful compose



## Bodhi
Goal of this Initiative
---
This initiative is to separate Bodhi into multiple sub packages, fix 
integration and unit tests in CI, fix dependency management and automate 
part of the release process.
Read ARC team findings in detail at: 
https://fedora-arc.readthedocs.io/en/latest/bodhi/index.html


Updates
---
* Move Bodhi from python-openid to OIDC (ongoing)
* Automate staging process for RPM building in Koji (ongoing)
* Dependency management via Poetry and dependabot (ongoing)


## EPEL
Goal of this initiative
---
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special 
Interest Group that creates, maintains, and manages a high quality set 
of additional packages for Enterprise Linux, including, but not limited 
to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), 
Oracle Linux (OL).


EPEL packages are usually based on their Fedora counterparts and will 
never conflict with or replace 

Re: The New Hotness 1.0.0 deployed on production

[Michal Konecny]

Anitya doesn't removing versions on it's own. This needs to be done by 
admin. The filter is just for the new versions that are retrieved by 
Anitya. This should be fixed in the future when The New Hotness will 
learn to work with pre-releases. I also plan to add new option to 
src.fedoraproject.org to notify only about stable versions.


Michal

P.S.: I removed the beta versions from Anitya project for you.

On 13. 12. 21 18:11, Fabio Valentini wrote:

On Mon, Dec 13, 2021 at 11:41 AM Michal Konecny  wrote:


Do you have an example? Because this is a bug. If the project doesn't
have some strange versioning scheme the stable should be still
considered newer than pre-release and the message should be emitted and
processed by The New Hotness.

Here's an example:

https://release-monitoring.org/project/141635/

After getting notifications for the first 2.0.0-beta releases, I added
a version filter to exclude alpha;beta versions.
But upstream kept releasing versions 1.9.0, 1.9.1, 1.9.2, etc. after
that, which are not considered *newer* than the last 2.0.0-beta
version anitya saw, so we don't get bugs for them. So this is not a
problem with a strange versioning scheme, but with anitya not removing
versions from its database, I guess.

Fabio
___
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: The New Hotness 1.0.0 deployed on production

[Michal Konecny]

This would create a vast amount of bogus notifications and there are 
multiple reasons why:
1) Editing the project in Anitya (this could create a really strange 
versions, especially for custom backend)
2) Creating a new project in Anitya (the first check usually retrieves 
large amount of new versions)
3) Not every project is checked for tarballs (there are plenty of 
backends, that are checking tags or parsing html, which could be in some 
cases anything, but versions)
4) Deleting versions in Anitya and retrieving them again (this could 
create a large amount of new versions that are retrieved) - this is 
needed if the project was incorrectly setup and needs to be edited
5) Incorrectly setup project in Anitya (this will just send you some 
weird versions that don't need to be correct at all)


But this is the issue I plan to address in the future, because I 
understand that the people want to be notified about every new version 
released upstream not only latest. The issue here is to recognize 
version that is really new and not something that was already reported, 
just resend by Anitya. I needd to come with some solution that wouldn't 
create massive amount of false warnings.


Right now The New Hotness is considered to help primarily with Rawhide 
and the latest version of the project. I hope it's doing this service well.


Michal

On 09. 12. 21 21:23, Michael Catanzaro wrote:
I honestly don't understand what the problem is. Why not simply notify 
whenever there is a new upstream tarball, regardless of what the 
version looks like? Trying to compare versions is pointless because we 
have as many as four different Fedora releases to maintain at any 
given time and they could all require updates from different upstream 
branches.


___
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: The New Hotness 1.0.0 deployed on production

[Michal Konecny]

On 09. 12. 21 21:15, Miro Hrončok wrote:

On 09. 12. 21 18:34, Fabio Valentini wrote:

On Thu, Dec 9, 2021 at 2:57 PM Miro Hrončok  wrote:


On 09. 12. 21 13:54, Michal Konecny wrote:

Hello everyone,

The New Hotness 1.0.0 is now live in Fedora infra production 
environment. For
those who don't know what this app does, it basically notifying 
packagers about

new versions of packages by creating bugzilla issues.

And what is new:
* The New Hotness was rewritten from scratch using clean 
architecture design

(it's now easier to maintain and less error prone)
* Documentation[0] was updated to be more useful and up to date
* The comments created in bugzilla should be more helpful and 
contain info

about errors if any happens during the scratch build
* The New Hotness now remembers the Koji Task ID,even if there is 
error in post
scratch build. In past the task ID was just lost and when the build 
was

finished The New Hotness couldn't recognize it
* We now have a containerized workflow for development

If you want to look at full changelog, please visit the-new-hotness 
GitHub

release page [1].


Awesome!

Let me use this as an opportunity to ask:
How can I disable reporting of pre-releases?


The only way I can think of to "ignore" pre-releases is to add a
"Version filter" on release-monitoring.org ...
I've started adding a "alpha;beta;rc;pre" filter (and set the
versioning to "semantic" to make sure they are sorted correctly) to
all Rust packages I touch, because we don't package pre-releases
except in rare circumstances.

Bt that only prevents anitya from fetching *new* pre-releases that
match that filter, it doesn't remove those that are already in the
database, and you won't get notifications for "new" versions that are
"older" than the latest pre-release :(


Hopefully for Python packages, this should be fixed in the future with:

https://github.com/fedora-infra/anitya/pull/1175

Maybe it can be solved similarly for Rust packages?
The New Hotness is still using RPM comparison for deciding if the 
version is newer than the old one regardless of how the versions are 
sorted in Anitya.


And in the future, The New Hotness will process all the new versions 
found by Anitya not only the newest one, this is why the 
anitya.project.version.update.v2 message topic was created. This is 
already prepared on Anitya side, but I still must implement it on The 
New Hotness side.


Michal
___
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: The New Hotness 1.0.0 deployed on production

[Michal Konecny]

On 09. 12. 21 18:34, Fabio Valentini wrote:

On Thu, Dec 9, 2021 at 2:57 PM Miro Hrončok  wrote:

...

The only way I can think of to "ignore" pre-releases is to add a
"Version filter" on release-monitoring.org ...
I've started adding a "alpha;beta;rc;pre" filter (and set the
versioning to "semantic" to make sure they are sorted correctly) to
all Rust packages I touch, because we don't package pre-releases
except in rare circumstances.

Bt that only prevents anitya from fetching *new* pre-releases that
match that filter, it doesn't remove those that are already in the
database, and you won't get notifications for "new" versions that are
"older" than the latest pre-release :(
Do you have an example? Because this is a bug. If the project doesn't 
have some strange versioning scheme the stable should be still 
considered newer than pre-release and the message should be emitted and 
processed by The New Hotness.


Michal


Fabio
___
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: The New Hotness 1.0.0 deployed on production

[Michal Konecny]

If you think this will be a fine feature for The New Hotness, please 
feel free to file a ticket in 
https://github.com/fedora-infra/the-new-hotness/issues


Michal

On 09. 12. 21 16:49, Jerry James wrote:

On Thu, Dec 9, 2021 at 8:32 AM Michal Konecny  wrote:

The New Hotness uses RPM version comparison for this and if this fails,
there isn't much we can do about it. See
https://github.com/fedora-infra/the-new-hotness/blob/2b3f7d7c2af847a48d190cab952125e7ccb97690/hotness/common/rpm.py#L32
if you want to look at how the compare method is implemented.

We still want to only report versions that are considered newer by RPM
comparison method.

How about reporting all versions that are newer than the package
version in Rawhide, whether or not they are newer than other
previously reported versions?

___
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: The New Hotness 1.0.0 deployed on production

[Michal Konecny]

The information is not lost (it's already emitted by Anitya in 
anitya.project.version.update.v2 message topic), The New Hotness just 
don't know how to work with it yet. It's planned as an upcoming feature.


Michal

On 09. 12. 21 16:54, Michael Catanzaro wrote:
On Thu, Dec 9 2021 at 03:59:39 PM +0100, Michal Konecny 
 wrote:

The New Hotness uses RPM version comparison for this and if this fails,
there isn't much we can do about it. See
https://github.com/fedora-infra/the-new-hotness/blob/2b3f7d7c2af847a48d190cab952125e7ccb97690/hotness/common/rpm.py#L32 


if you want to look at how the compare method is implemented.


What's sad is that release-monitoring.org knows exactly which release 
is prerelease and which release is stable, so it's a shame that info 
gets lost somewhere before it manages to report a bug. Bug reports are 
nice, but some other mechanism for release notifications that doesn't 
lose the release information would be even better


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam 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: The New Hotness 1.0.0 deployed on production

[Michal Konecny]

On 09. 12. 21 15:20, Michael Catanzaro wrote:
On Thu, Dec 9 2021 at 02:25:11 PM +0100, Miro Hrončok 
 wrote:

Let me use this as an opportunity to ask:
How can I disable reporting of pre-releases?


I have the opposite question. Previously, once a pre-release tarball 
was available, the new hotness would stop reporting when a new stable 
tarball becomes available. Is that fixed?
The New Hotness uses RPM version comparison for this and if this fails, 
there isn't much we can do about it. See 
https://github.com/fedora-infra/the-new-hotness/blob/2b3f7d7c2af847a48d190cab952125e7ccb97690/hotness/common/rpm.py#L32 
if you want to look at how the compare method is implemented.


We still want to only report versions that are considered newer by RPM 
comparison method.


___
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: The New Hotness 1.0.0 deployed on production

[Michal Konecny]

On 09. 12. 21 14:25, Miro Hrončok wrote:

On 09. 12. 21 13:54, Michal Konecny wrote:

Hello everyone,

The New Hotness 1.0.0 is now live in Fedora infra production 
environment. For those who don't know what this app does, it 
basically notifying packagers about new versions of packages by 
creating bugzilla issues.


And what is new:
* The New Hotness was rewritten from scratch using clean architecture 
design (it's now easier to maintain and less error prone)

* Documentation[0] was updated to be more useful and up to date
* The comments created in bugzilla should be more helpful and contain 
info about errors if any happens during the scratch build
* The New Hotness now remembers the Koji Task ID,even if there is 
error in post scratch build. In past the task ID was just lost and 
when the build was finished The New Hotness couldn't recognize it

* We now have a containerized workflow for development

If you want to look at full changelog, please visit the-new-hotness 
GitHub release page [1].


Awesome!

Let me use this as an opportunity to ask:
How can I disable reporting of pre-releases?
Unfortunately, the only option now is to edit the project in Anitya to 
obtain only stable versions.


There will be option for it in The New Hotness in the future, but 
currently it can't recognize stable and pre-release version from each other.

___
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

The New Hotness 1.0.0 deployed on production

[Michal Konecny]

Hello everyone,

The New Hotness 1.0.0 is now live in Fedora infra production 
environment. For those who don't know what this app does, it basically 
notifying packagers about new versions of packages by creating bugzilla 
issues.


And what is new:
* The New Hotness was rewritten from scratch using clean architecture 
design (it's now easier to maintain and less error prone)

* Documentation[0] was updated to be more useful and up to date
* The comments created in bugzilla should be more helpful and contain 
info about errors if any happens during the scratch build
* The New Hotness now remembers the Koji Task ID,even if there is error 
in post scratch build. In past the task ID was just lost and when the 
build was finished The New Hotness couldn't recognize it

* We now have a containerized workflow for development

If you want to look at full changelog, please visit the-new-hotness 
GitHub release page [1].


Thanks to everybody who contributed to this release!

Regards,
Michal
Mage from release-monitoring.org

[0] - https://the-new-hotness.readthedocs.io/en/stable/
[1] - https://github.com/fedora-infra/the-new-hotness/releases/tag/1.0.0
___
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

CPE Weekly Update – Week of December 6th – 10th

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering)
Team. If you have any questions or feedback, please respond to this
report or contact us on #redhat-cpe channel on libera.chat
(https://libera.chat/).

If you wish to read this in form of a blog post, check the post on
Fedora community blog:
https://communityblog.fedoraproject.org/cpe-weekly-update-week-of-december-6th-10th/

# Highlights of the week

## Infrastructure & Release Engineering
Goal of this Initiative
---
Purpose of this team is to take care of day to day business regarding
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS
infrastructure and preparing things for the new Fedora release
(mirrors, mass branching, new namespaces etc.). The ARC (which is a
subset of the team) investigates possible initiatives that CPE might
take on.

Update
--

### Fedora Infra
* Discourse2fedmsg completed and deployed in prod
* groups support for oauth2 for discourse put on hold due to a potential 
upstream solution

* Switched to qemu/libvirt from the “Advanced Virt” stack
* All staging builders moved to f35, but our fedora messaging plugin is 
broken in f35 hub.

* New bodhi deployment this week


### CentOS Infra including CentOS CI
* CentOS Stream 9 [artwork 
deployed](https://pagure.io/centos-infra/issue/477) (Kudos to Artwork 
SIG !) :

  * https://www.centos.org
  * https://blog.centos.org
  * https://lists.centos.org
* Meeting[s] to prepare the Community Cage DC move
* Identified (and [fixed](https://pagure.io/centos-infra/issue/551)) 
small issue for PowerDNS geoip setup for 9-stream
* Bussiness as Usual (koji/cbs tags, new mirrors for 7 / 8-stream and 
9-stream)




### Release Engineering
* epel9 branches are popping up ~520 in the last week
* F36 change request reviews are landing in releng tracker
* business as usual


## CentOS Stream
Goal of this Initiative
---
This initiative is working on CentOS Stream/Emerging RHEL to make this
new distribution a reality. The goal of this initiative is to prepare
the ecosystem for the new CentOS Stream.

Updates
---
* Stream 9 composes were broken over the weekend, the backlog is now 
clear and a compose was pushed yesterday
* Gitlab authentication suffered some effects of the auth.redhat.com 
migration, we expect this is now resolved

* Implementing Content Resolver performance optimisations


## CentOS Duffy CI
Goal of this Initiative
---
Duffy is a system within CentOS CI Infra which allows tenants to 
provision and

access bare metal resources of multiple architectures for the purposes of
CI testing.
We need to add the ability to checkout VMs in CentOS CI in Duffy. We have
OpenNebula hypervisor available, and have started developing playbooks which
can be used to create VMs using the OpenNebula API, but due to the 
current state

of how Duffy is deployed, we are blocked with new dev work to add the
VM checkout functionality.

Updates
---
* API endpoints with database connection (finally)
* Extended documentation for API endpoints (in progress)
* Command-line option to avoid overriding existing database when 
performing migration

* Backend work (started): Background tasks like provisioning nodes, clean up
* Endpoint authentication with API key / token pertaining to a certain 
project / tenant (in progress)




## OSCI – Distrobaker monitoring
Goal of this Initiative
---
This initiative is to improve the Distrobaker monitoring to monitor
side-tags and module builds. Distrobaker is a service which rebuilds
the CentOS 9 Stream Koji builds for RHEL 9 in Brew.

Updates
---
* Currently working on adding metrics for the sidetag comparison code.

## EPEL
Goal of this initiative
---
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest
Group that creates, maintains, and manages a high quality set of additional
packages for Enterprise Linux, including, but not limited to, Red Hat
Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux 
(OL).


EPEL packages are usually based on their Fedora counterparts and will never
conflict with or replace packages in the base Enterprise Linux 
distributions.

EPEL uses much of the same infrastructure as Fedora, including buildsystem,
bugzilla instance, updates manager, mirror manager and more.

Updates
---
* [EPEL9 (and EPEL9 Next) 
launched!](https://communityblog.fedoraproject.org/epel-9-is-now-available/)

* Already have 501 packages in testing (255 builds, 158 bodhi updates)
* [Quickstart 
documentation](https://docs.fedoraproject.org/en-US/epel/#_quickstart) 
updated
* EPEL Steering Committee [decided to 
standardize](https://pagure.io/epel/issue/133) on 
{distro}+epel-{version} pattern for mock configs rather than a generic 
epel-{version} config

* centos-stream+epel-9 configs added to mock-core-configs

CPE Weekly Update – Week of November 08th – 12nd

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering)
Team. If you have any questions or feedback, please respond to this
report or contact us on #redhat-cpe channel on libera.chat
(https://libera.chat/).

If you wish to read this in form of a blog post, check the post on
Fedora community blog:
https://communityblog.fedoraproject.org/cpe-weekly-update-week-of-november-08th-12nd/

# Highlights of the week

## Infrastructure & Release Engineering
Goal of this Initiative
---
Purpose of this team is to take care of day to day business regarding
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS
infrastructure and preparing things for the new Fedora release
(mirrors, mass branching, new namespaces etc.). The ARC (which is a
subset of the team) investigates possible initiatives that CPE might
take on.

Update
--

### Fedora Infra
* Out of freeze, merged a bunch of post freeze work, more to come
* Dnssec records finally fully updated away from sha-1
* Ibiblio hosts ipv6 all moved off old net/block
* Attempted to move s390x builders to new mainframe, but hit issues, 
going to try again next week.

* Fedora koji upgraded to latest upstream


### CentOS Infra including CentOS CI
* Business as usual

### Release Engineering
* Epel 9 next is in bodhi
* New side tag for f35-kde
* Business as usual


## CentOS Stream
Goal of this Initiative
---
This initiative is working on CentOS Stream/Emerging RHEL to make this
new distribution a reality. The goal of this initiative is to prepare
the ecosystem for the new CentOS Stream.

Updates
---
* We’ve updated RHEL 9 branching images in Dev Guide
* Working on documentation and tidying up docs locations on the compose 
reporting work showing the diffs between RHEL/c8s/c9s composes
* Package additions from RHEL appstream coming through to be added to 
CentOS Stream repos
* Content resolver logic has been reviewed and re-written to accommodate 
a new buildroot functionality and working through adding package 
placeholders



## CentOS Duffy CI
Goal of this Initiative
---
Duffy is a system within CentOS CI Infra which allows tenants to 
provision and

access bare metal resources of multiple architectures for the purposes of
CI testing.
We need to add the ability to checkout VMs in CentOS CI in Duffy. We have
OpenNebula hypervisor available, and have started developing playbooks which
can be used to create VMs using the OpenNebula API, but due to the 
current state

of how Duffy is deployed, we are blocked with new dev work to add the
VM checkout functionality.

Updates
---
* Finished Work In Progress from last week
  * Logging
  * Database model
  * Configuration Framework
* Tests started working successfully on Python 3.10, by magic! Test 
against Python 3.6 ~ 3.10 in CI.

* Work In Progress
  * API endpoints for all the things
  * Planning delegating to bare metal and OpenNebula (VMs)



## FCOS OpenShift migration
Goal of this Initiative
---
Move current Fedora CoreOS pipeline from the centos-ci OCP4 cluster to 
the newly

deployed fedora infra OCP4 cluster.

Updates
---
* New Openshift role sysadmin-openshift to handle 
installation/configuration of OCP 4 tasks

* Added oc client for ocp4 to the batcave01 PR
* Pushed changes to allow connections from batcave01 to the ocp4 
cluster, follow on ticket opened with RH IT to open ports in firewall also.



## EPEL
Goal of this initiative
---
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special 
Interest Group that creates, maintains, and manages a high quality set 
of additional packages for Enterprise Linux, including, but not limited 
to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), 
Oracle Linux (OL).


EPEL packages are usually based on their Fedora counterparts and will 
never conflict with or replace packages in the base Enterprise Linux 
distributions. EPEL uses much of the same infrastructure as Fedora, 
including buildsystem, bugzilla instance, updates manager, mirror 
manager and more.


Updates
---
* Fedora s390x builder migration was not successful, had to be rolled 
back and rescheduled, so epel9-next is still blocked
* Epel9-next has been added to bodhi, allowing us to test the push 
pipeline with noarch packages (epel-release and epel-rpm-macros)

* Additional ancillary work in mock-core-configs, bodhi, and fedpkg


Kindest regards,
CPE Team
___
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 

CPE Weekly Update – Week of October 18th – 22nd

[Michal Konecny]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering)
Team. If you have any questions or feedback, please respond to this
report or contact us on #redhat-cpe channel on libera.chat
(https://libera.chat/).

If you wish to read in form of blog post, check the post on
Fedora community blog:
https://communityblog.fedoraproject.org/cpe-weekly-update-week-of-october-18th-22nd/

# Highlights of the week

## Infrastructure & Release Engineering
Goal of this Initiative
---
Purpose of this team is to take care of day to day business regarding
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS
infrastructure and preparing things for the new Fedora release
(mirrors, mass branching, new namespaces etc.). The ARC (which is a
subset of the team) investigates possible initiatives that CPE might
take on.

Update
--

### Fedora Infra
* Fixed fasjson in stg (was stuck on a image pull)
* Added 200GB to ostree netapp volume
* Retired iddev and simple-koji-ci cloud instances
* Declared the sssd bug fixed (hadn’t happened in 2 weeks)


### CentOS Infra including CentOS CI
* Stream 9 available in CI (x86_64 only though)
    * Newer python-cicolient
    * Duffy2 hotfix for paramiko issue with el9
* Exploring options for secureboot for SIGs
* Deploying Duffy Dev Lab for initiative
* Business as usual (new tags created for SIGs, ….)


### Release Engineering
* Updated critpath packages for all releases
* F35 final RC request landed
    * Compose is finished with incomplete state armhfp container 
aarch64 KDE and failed


## CentOS Stream
Goal of this Initiative
---
This initiative is working on CentOS Stream/Emerging RHEL to make this
new distribution a reality. The goal of this initiative is to prepare
the ecosystem for the new CentOS Stream.

Updates
---
* Work continues on Content Resolver buildroot support
* We're now running repoclosure before we sync to the mirrors


## Datanommer/Datagrepper V.2
Goal of this Initiative
---
The datanommer and datagrepper stacks are currently relying on fedmsg which
we want to deprecate.
These two applications need to be ported off fedmsg to fedora-messaging.
As these applications are 'old-timers' in the fedora infrastructure, we 
would
also like to look at optimizing the database or potentially redesigning 
it to

better suit the current infrastructure needs.
For a phase two, we would like to focus on a DB overhaul.

Updates
---
* Import crashed because of a database schema design decision that 
didn’t account for the size of our messages, it's fixed and the import 
started again because the schema update on existing data would take a 
lot of time too. ETA is back to 70 days.



## CentOS Duffy CI
Goal of this Initiative
---
Duffy is a system within CentOS CI Infra which allows tenants to 
provision and

access bare metal resources of multiple architectures for the purposes of
CI testing.
We need to add the ability to checkout VMs in CentOS CI in Duffy. We have
OpenNebula hypervisor available, and have started developing playbooks which
can be used to create VMs using the OpenNebula API, but due to the 
current state

of how Duffy is deployed, we are blocked with new dev work to add the
VM checkout functionality.

Updates
---
* Took stock and decided to rewrite
* Cleaned up branches
* Boilerplate work


Kindest regards,
CPE Team
___
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: CPE Feedback Survey

[Michal Konecny]

Hi everyone,

we still want your feedback about your experiences with the CPE Team. 
The survey will take only few minutes and there is still some time left 
before the survey will be closed.


Here is the link to survey https://fedoraproject.limequery.com/4?lang=en 



On behalf of CPE,
Michal

On 03. 02. 21 12:48, Ant Carroll wrote:
Hey folks, Apologies for the delay in getting this out to you after 
the start of the year. Hopefully you've noticed the changes to 
communication since the results of the last survey we did in August. 
However, we know this is ever changing, people join or become inactive 
and so want to ensure we continue with making improvements that 
benefit us all. I'm here asking for your help with this again Here 
is a link to a very short survey we've put together to learn how your 
experiences have been with the CPE team since October 2020. If you 
could take the time (5mins max) to complete it for us it would be 
hugely valuable as we work on this continuous improvement - 
https://fedoraproject.limequery.com/4?lang=en 


The survey will remain open until Feb 17th (23:59 UTC).
Cheers, Ant --

Ant Carroll

Associate Manager, Software Engineering

Red Hat Waterford 

Communications House

Cork Road, Waterford City

ancar...@redhat.com 
M: +353876213163  IM: ancarrol

@redhatjobs  redhatjobs 
 @redhatjobs 





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

Re: the-new-hotness is broken?

[Michal Konecny]

The fix is deployed to production.

Michal

On 04. 02. 21 10:23, Michal Konecny wrote:
I will work on the fix today. Not happy about this useless change that 
just broke plenty of scripts.


Michal

On 04. 02. 21 0:23, Kevin Fenzi wrote:

On Wed, Feb 03, 2021 at 05:41:27PM -0500, Elliott Sales de Andrade wrote:

I just received 3 notifications that


the-new-hotness saw an update for , but pkgdb says the maintainers are 
not interested in bugs being filed

but all packages have monitoring enabled.

Did something break with it? Maybe the branch name changes?

Indeed it did. Filed:
https://github.com/fedora-infra/the-new-hotness/issues/318

on it.

Looks like it looks for a 'master' branch to tell if a package is
retired or not. ;(

kevin

___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org




___
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: the-new-hotness is broken?

[Michal Konecny]

I will work on the fix today. Not happy about this useless change that 
just broke plenty of scripts.


Michal

On 04. 02. 21 0:23, Kevin Fenzi wrote:

On Wed, Feb 03, 2021 at 05:41:27PM -0500, Elliott Sales de Andrade wrote:

I just received 3 notifications that


the-new-hotness saw an update for , but pkgdb says the maintainers are 
not interested in bugs being filed

but all packages have monitoring enabled.

Did something break with it? Maybe the branch name changes?

Indeed it did. Filed:
https://github.com/fedora-infra/the-new-hotness/issues/318

on it.

Looks like it looks for a 'master' branch to tell if a package is
retired or not. ;(

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


___
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

Unavailability of some fedoraproject.org services

[Michal Konecny]

Hi everyone,

we are currently experiencing network issues in IAD2 datacenter. There 
are plenty of services on fedoraproject.org unavailable right now. 
Please stay calm and don't ping us on IRC.


If you want to follow the issue, we have a ticket for this [0].

On behalf of Fedora Infrastructure team,
Michal

[0] - https://pagure.io/fedora-infrastructure/issue/9051

--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez
___
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: CPE Git Forge Decision

[Michal Konecny]

On 03/04/2020 01:25, Jeremy Cline wrote:

On Thu, 2020-04-02 at 11:52 +0100, Leigh Griffin wrote:

The number of active developers on Fedora initiatives has gone up
drastically since I joined the team in 2019. You are possibly not
seeing that as the team have moved from a model of siloed work on
multiple apps, swimming against the tid working 16 hour days, to
working on team oriented initiatives to add real value to the
ecosystem. So the noise of working on multiple small things at once
is not as loud as it was in 2018 which is giving that illusion.

I'd always suspected my work added no real value, but never had the
proof. I appreciate the validation .

- Jeremy
I bow before you mighty Jeremy and the work you did. The fedora 
messaging is really nice replacement of the fedmsg, although is not used 
by every application yet.


I also want to thank you for handing me off the Anitya and 
the-new-hotness. It helped me grow my wizard realm in Fedora Universe. :-)


Michal
Wizard from release-monitoring.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


--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez
___
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: CPE Git Forge Decision

[Michal Konecny]

On 02/04/2020 23:51, Björn Persson wrote:

Paul Frields wrote:

That statement rings hollow for me, when Github is arguably the single
biggest vendor of open source in the world, no part of itself is open
source, and thanks to its pervasiveness, open source has won the war
of how development should work.

Github shows that *proprietary centralized services* are winning the war
of how development should work. Gitlab is a smaller, competing,
proprietary centralized service.

This trend is not in any way unique to software development. Pretty much
everything is being consolidated into centralized services governed by a
small number of corporate behemoths. Every new thing is launched as a
proprietary service that captures the market before anyone has a chance
to develop a decentralized competitor. Even those decentralized networks
that have existed since the Internet was young are now degenerating into
centralized services. The smaller players will continue to be bought by
bigger competitors until there are only one or two services in the world
for doing whatever you want to do.
There is plenty of decentralized open source solutions for plenty of 
services [0]. Unfortunately not for git forge.


Michal

[0] - https://fediverse.party/


I speak only for myself but it seems to me that concern over this
ongoing centralization is why people are objecting to moving to Github
or Gitlab.

Björn Persson

___
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


--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez

___
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: CPE Git Forge Decision

[Michal Konecny]

On 01/04/2020 10:53, Vít Ondruch wrote:



Dne 01. 04. 20 v 10:37 Michal Konecny napsal(a):



On 31/03/2020 20:53, Kevin Fenzi wrote:

On Tue, Mar 31, 2020 at 12:40:55PM -0500, Bruno Wolff III wrote:
...snip...

Because of switching costs, this is likely to prevent us from going back to
Pagure if it does develop a vibrant independent community. That would be
unfortunate.

So, currently we are using pagure on src.fedoraproject.org, but it's not
just pagure, it's a integration layer over the top of pagure too.

I'd like to see if we can, as part of this: a) adjust our packaging
workflow (as many threads on this list have talked about) and b) after
that, try and reduce that integration layer as much as we can and c)
hopefully make it so we could move the backend git repos / forge later
if we wanted to without recreating a big integration layer.
To be clear, you mean something like app above the dist-git where you 
could do most of the things that are needed for dist-git with git 
forge only being a package source with various branches?


Something like web UI that allows you to do retirement, change 
notification settings, has links to various other systems, with on of 
them the git that is hosting the code for package, without actually 
thinking what git forge is used for the hosting?



Do you mean https://github.com/fedora-infra/pkgdb2/ ? :)


Vít


I meant something more user friendly, this is just an API, which is not 
easy to use for everyone.


Michal




If yes, than I'm into this and it doesn't matter for me where the 
packages are hosted anymore.


Michal

As part of that we could also provide whats needed for the integration
and the pagure community could add anything they don't already have on
their roadmap.

kevin

___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez

___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
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


--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez

___
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: CPE Git Forge Decision

[Michal Konecny]

On 31/03/2020 20:53, Kevin Fenzi wrote:

On Tue, Mar 31, 2020 at 12:40:55PM -0500, Bruno Wolff III wrote:
...snip...

Because of switching costs, this is likely to prevent us from going back to
Pagure if it does develop a vibrant independent community. That would be
unfortunate.

So, currently we are using pagure on src.fedoraproject.org, but it's not
just pagure, it's a integration layer over the top of pagure too.

I'd like to see if we can, as part of this: a) adjust our packaging
workflow (as many threads on this list have talked about) and b) after
that, try and reduce that integration layer as much as we can and c)
hopefully make it so we could move the backend git repos / forge later
if we wanted to without recreating a big integration layer.
To be clear, you mean something like app above the dist-git where you 
could do most of the things that are needed for dist-git with git forge 
only being a package source with various branches?


Something like web UI that allows you to do retirement, change 
notification settings, has links to various other systems, with on of 
them the git that is hosting the code for package, without actually 
thinking what git forge is used for the hosting?


If yes, than I'm into this and it doesn't matter for me where the 
packages are hosted anymore.


Michal


As part of that we could also provide whats needed for the integration
and the pagure community could add anything they don't already have on
their roadmap.

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


--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez

___
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: Git Forge Requirements: Please see the Community Blog

[Michal Konecny]

On 06/02/2020 22:13, Till Maas wrote:

On Tue, Jan 21, 2020 at 04:34:37PM +, Leigh Griffin wrote:


On behalf of the CPE team I want to draw the communities attention to a
recent blog post which you may be impacted by:
  https://communityblog.fedoraproject.org/git-forge-requirements/

We will be seeking input and requirements in an open and transparent manner
on the future of a git forge solution which will be run by the CPE team on

Aleksandra's comment made me aware that for dist-git, we do not really
need a git forge, it is just that the pagure git forge was used to
implement a lot of workflows that pkgdb provided in the past.

I tried to write the requirements as user stories to make them easier to
understand. What do you think?

- As a package maintainer, I can only commit to a dist-git repo, if I am
   in the Fedora packager group.
- As a package maintainer, I can only commit to a dist-git repo, if I am
   a maintainer of the branch.
- As a proven packager, I can commit to all dist-git repos that do not
   have special restrictions set by FESCo or are retired.
- As a FESCO member, I can configure exceptions to disallow proven
   packager access to a dist-git repo.
- As dist-git repo admin, I can easily add other maintainers to allow
   commit or admin access for dist-git repo by using their FAS username
- As a dist-git repo admin, I cannot remove access to the repo from
   Fedora infra, Releng or proven packagers without FESCo approval.
- As a package maintainer, I can easily orphan a dist-git repo or branch
   to show that it is not maintained anymore.
- As a package maintainer, I can adopt any orphaned dist-git repo or
   branch.
- As a package maintainer, I can easily unretire a retired dist-git repo
   or branch.
- As a release engineer, I can easily approve unretire requests for a
   dist-git repo or branch.
- As anybody, I can easily see the FAS usernames of maintainers for all
   branches of a dist-git repo.
- As a non-releng member, I cannot remove any commits from any dist-git
   repo that were used to build a Fedora package.
- As an external user, I can easily get a list of all orphaned or
   retired dist-git repos and branches.
- As anybody, I can watch for issues (bugzillas) or PRs that are created
   for a dist-git repository.
- As anybody, I can easily get a list of all dist-git repos that I am
   watching.
- As anybody, I can easily get a list of all dist-git repos that a
   specific Fedora account has admin/commit access to.
- As anybody, when looking at the dist-git repo it is clearly visible
   which branches are still maintained.
- As anybody, when I look for a specific branch, EOL branches do not
   clutter my view.
- As a package maintainer, I can easily request commit/admin access for
   a specific branch or dist-git repo.

I add one more requirement based on my own workflow:
- As fedora user, I want to easily create pull requests to any dist-git 
repo.


Michal


Also since dist-git is a critical part of our infrastructure, there
should probably also be some security-related requirements such as:

- As Fedora infra, I can easily audit that no git repo was accessed
   without authorization.
- As Fedora infra/security response team, I have access to secure logs
   to analyse the impact of unauthorized access to all dist-git repos.
- As anybody, the dist-git web page of a repo points me to Bugzilla to
   report issues for a repository.

I did not manage to read all other replies, so there might be some
duplicates but it also seems to me that many of these items were not
mentioned.

Kind regards
Till
___
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


--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez
___
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: Anitya Upstream Release Monitoring - Dial back Auto-Bugzilla ticket generation

[Michal Konecny]

Hi,

each project is checked for new version once per hour. There is a 
service running that is creating a queue from the projects that would be 
checked. It was just a coincidence that your project was checked at the 
same time you uploaded a new version. But if you are an upstream 
maintainer, I recommend to turn off the monitoring as was recommended 
later in this thread.


Michal

On 01/02/2020 22:05, Chris wrote:

Hi,

I was just curious if there as a way to dial back the Upstream Release 
Monitoring and the automatic Bugzilla ticket generation from it?


I pushed a new release of my software to PyPi and I swear before I 
even got access to the shell again (from the successful twine upload 
message), I was already alerted by Anitya that a Bugzilla ticket has 
been created.


Can we dial this back and give ... say.. 24 hours or so before 
creating these tickets (when a new version is detected)? Just a 
question is all.  It's also possible this is just it's an option that 
I carelessly overlooked (i do tend to do these things)?


I think the ticket is fantastic and very useful, I just think it 
should be triggered after a longer wait period then 3μs :)


Thoughts?

Chris

___
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


--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez

___
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: Git Forge Requirements: Please see the Community Blog

[Michal Konecny]

On 31/01/2020 12:11, Vít Ondruch wrote:

Dne 31. 01. 20 v 1:43 Neal Gompa napsal(a):

On Thu, Jan 30, 2020 at 6:51 PM Randy Barlow
 wrote:

On Thu, 2020-01-30 at 10:30 +0100, Vít Ondruch wrote:

cough cough errata cough cough

Honestly, sometimes the disconnect between what is going on in Fedora
and internally in Red Hat is intriguing.

I did think about Errata tool* a bit back when I worked on Bodhi.


Thank you for that.



  I
like the idea of sharing code on one hand, but on the other hand it is
pretty oriented towards workflows that are designed for a product
release cycle. Bodhi is designed around community feedback (and now CI
feedback).

It could be interesting to hold a chat with the Errata tool developers
to see if there is interest in sharing tooling, but it may be a lot of
effort to make Errata tool flexible enough to support two pretty
different workflows. I'd be willing to have that conversation; I could
be wrong.


Of course, there is a lot of business logic specific to Red Hat projects
backed into Errata, but ultimately, it does not help to anybody if
Fedora release process is using different tools then Red Hat internally.
What Red Hat does internally should be just extension to what Fedora
does. The processes used internally should be proven in Fedora first.
This is a very nice vision that will potentially make life of Red Hat 
and Fedora much easier. I'm not that long in the Fedora project to know, 
why Fedora and Red Hat internal tools are that different, but this idea 
doesn't sound that bad. Few questions first:

Are those internal tools open source?
Could we as Fedora community use them?
Is there any legal issue?
Is this tool in good shape?

And talking about the git forge, what is Red Hat using internally as git 
forge? And then the above questions applies.


Michal




Why not go the other way? Bodhi could be extended to support the
internal product workflows.




In ideal world, Bodhi would be upstream project to Errata or possibly
Bodhi could be the open core of Errata. It does not really matter.


Vít

___
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


--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez
___
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: Git Forge Requirements: Please see the Community Blog

[Michal Konecny]

On 21/01/2020 23:13, John M. Harris Jr wrote:

On Tuesday, January 21, 2020 2:31:47 PM MST Michael Catanzaro wrote:

On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa  wrote:


And any discussion of GitHub isn't going to involve self-hosted, it's
going to involve GitHub.com, which means we're talking about losing
more of our independence as a project. This is one of those things
that I'm not sure is a wise move.


Well since we have a request for requirements: I propose requirements
#1 and #2 are to be self-hosted and open source. I'm suspect the Fedora
community would be outraged if we fail to meet either requirement.

So if we can agree on that much, then we can avoid wasting time by
including GitHub in the list of options. That would bring us to a
choice between GitLab CE and Pagure. (Are there any other serious
options?)

Michael

Both Gitea and Gogs are potential options, in my opinion, both are lightweight
and easy to extend.

If we go this way, in a few years we will end up in the same situation 
as with Pagure today. We will have many custom patches (which we need to 
take care of) and we will not have manpower to compete with the features 
of other major git forges.


--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez
___
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: Let's talk about Fedora in the '20s!

[Michal Konecny]

I think, and this is my personal opinion, that Ubuntu is so popular, 
because it is easy to use for everyone. You don't need to have much 
technical knowledge to use Ubuntu for most thinks that non technical 
user needs and it looks good.


Every time I'm trying to use Fedora the same way, I always end up in 
terminal for various reasons, either because of bugs in some software or 
debugging something that simply doesn't work.


I tried a experiment on my desktop computer and tried to play with it 
like regular user (using GUI for everything and doing things like 
installing new things, watching movies, playing games etc.). It worked 
for some time, but I always encounter something that just broke things 
and if you google it, there is in most cases no way to fix this without 
using terminal and have some technical knowledge.


The same is for the guides. There are plenty of guides for Ubuntu with 
screenshots, so it's easy for users to just follow these guides. For 
Fedora we have plenty of guides that just have only commands you need to 
run and I know plenty of users that just don't know what command means 
or where they should write it.


Michal


On 07/01/2020 17:14, Iñaki Ucar wrote:

On Tue, 7 Jan 2020 at 16:38, Matthew Miller  wrote:

On Tue, Jan 07, 2020 at 03:22:45PM +0100, Iñaki Ucar wrote:

For me, the main challenge Fedora faces is **positioning**.

Let me explain: (I don't have numbers but) in my (limited) experience,
when seasoned sysadmins need to launch a new system, they usually
think "Debian" as something reliable; when seasoned as well as
not-very-seasoned-in-Linux research engineers (I know better this
category, since I'm a researcher) need to setup a system for some demo
or experiment, they mostly think "Ubuntu" (yes, I know...); when we
see a new exciting service (such as Travis CI and the like) coming
out, they usually support Ubuntu; and so on and so forth, and I'm not
even talking about the desktop use case.

So I think there's the challenge for Fedora, for all those people to
consider Fedora as a first option for their use cases.

I agree that's a challenge. Any ideas for how to address it and change these
perceptions?

I'm far from having a satisfactory response to that, but I see two
fronts here. First, marketing. How does Ubuntu managed to be so
popular among less-experienced Linux users? I'm not sure, but I
suspect that good marketing has something to do with it. Second,
exposure. If someone wants to configure a Travis CI instance, or a
Google Cloud instance for some data science pipeline, etc., etc., and
Fedora is there among the options available, then Fedora will
automatically come to mind as an option for the next project. Of
course that's not under our direct control, but if we know the
requirements for such third-party services, we can build specially
tailored spins and try to promote them in those
communities/projects/enterprises at all levels. So 1) stay on the
cutting edge, 2) make it as easy as possible to choose Fedora over
other options, and 3) marketing and promotion may be a good recipe.



--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez
___
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

Non-responsive maintainer wzzrd

[Michal Konecny]

Hi,

I'm sending this e-mail according to non-responsive maintainer policy 
with link to created issue in bugzilla: 
https://bugzilla.redhat.com/show_bug.cgi?id=1765093


This maintainer has also two other issues on him:
https://bugzilla.redhat.com/show_bug.cgi?id=1605696
https://bugzilla.redhat.com/show_bug.cgi?id=1605738

And PR I sent waiting for review:
https://src.fedoraproject.org/rpms/libyubikey/pull-request/1

If anybody knows how to contact this maintainer, please let him know.

Regards,
Michal

--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez
___
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: 2020 Datacenter Move: Request for comments

[Michal Konecny]

On 2019-10-02 16:45, Fabio Valentini wrote:

On Wed, Oct 2, 2019 at 3:07 AM Brian (bex) Exelbierd
 wrote:



On Tue, Oct 1, 2019 at 10:05 AM Pavel Valena  wrote:

- Original Message -

From: "Jun Aruga" 
To: "Development discussions related to Fedora" 
Cc: "Fedora Infrastructure" 
Sent: Monday, September 30, 2019 8:27:22 PM
Subject: Re: 2020 Datacenter Move: Request for comments


There's also a video about it from Flock 2019:
https://www.youtube.com/watch?v=phCHilTEQb4=PL0x39xti0_64C75dRUuwlXlfYRgjgdEP4=8=0s

Thanks. But why is the video mode "Unlisted" not public?

--
Jun | He - His - Him

Making it public is just a `cosmetic` change IMO, as the `Flock 2019` list is 
public. But maybe it enhances visibility(searchability?) also.

CCing Bex for comments. ;)


The ones in this list should be listed.  There are about 22 videos still to be 
reviewed for final clearance.  I am in 2 weeks of f2f meetings so i am trying 
to get to them ASAP.

Looking at the fedora youtube channel and the playlist, *all videos
except one* (Fedora Flatpaks) are still unlisted.

Fabio
This could explain, why I got notification only for Fedora Flatpaks 
video, when I'm subscribed to Fedora Channel on Youtube.


Michal



regards,

bex


Thanks,
Pavel



--
Brian "bex" Exelbierd (he/him/his)
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
bexel...@redhat.com | b...@pobox.com
___
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


--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez
___
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: Defining the future of the packager workflow in Fedora

[Michal Konecny]

On 2019-09-27 17:46, Randy Barlow wrote:

On Fri, 2019-09-27 at 10:26 +0200, Michal Konecny wrote:

There is still possibility to use libraries.io
instead of Anitya, but there are some issues:
- lack of downstream mapping (this could be easily solved by some
database with only downstream mapping)
- lack of custom project additions (libraries.io can only watch
projects
in sources they have already implemented)

libraries.io is open source:

https://github.com/librariesio

It would be good to work with them to add these features there, rather
than to make our own database with the downstream mapping. This way all
distros can benefit, and we also don't have to do all the work of
creating and maintaining our own project.
Yes, this will need to be done, if we decide to replace Anitya with 
libraries.io.


___
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: Defining the future of the packager workflow in Fedora

[Michal Konecny]

On 2019-09-26 20:35, Jeremy Cline wrote:

On Thu, Sep 26, 2019 at 09:08:16AM -0700, Adam Williamson wrote:

On Thu, 2019-09-26 at 15:46 +, Jeremy Cline wrote:

Ah right, that makes a lot of sense.

I can imagine automatically detecting the new upstream release, building
that, and presenting the packager with a easy-to-review PR that you just
click "merge" on instead of pointing the specfile at a new tarball.

This already basically happens, at least for things that are hooked up
to anitya:
https://bugzilla.redhat.com/show_bug.cgi?id=1751432
https://fedoraproject.org/wiki/Upstream_release_monitoring

You get a bug report with a patch attached, and it runs a scratch
build. This is great for simple release bumps, but there's still all
sorts of cases where it's not enough or you're just doing something
else.

I do have a little[0] experience with anitya, but it's not nearly as
hooked up as it could be and honestly Libraries.io generally does
better for tracking upstreams, it just lacks the mapping to downstreams.
Maybe we could add that and use it, or continue with anitya.

What I'd really like to see is a lot more "cleverness" from it regarding
versions and automatic backporting to various Fedora releases based on
semantic versioning. Also there's still manual steps you need to do as a
maintainer like downloading and then uploading the tarball.
As a current maintainer I thought about this one and I have already work 
in progress [0] that adds ability to create PR in dist-git directly 
using packit. With Fedora CI in place, this will be automatically 
tested. To get this work I'm missing mostly time to do it and new 
version of Pagure to be deployed.


Anitya still needs plenty of love, but right now Fedora Infra has 
priorities elsewhere. There is still possibility to use libraries.io 
instead of Anitya, but there are some issues:
- lack of downstream mapping (this could be easily solved by some 
database with only downstream mapping)
- lack of custom project additions (libraries.io can only watch projects 
in sources they have already implemented)


Michal

[0] - https://github.com/fedora-infra/the-new-hotness/pull/235


[0] https://github.com/release-monitoring/anitya/graphs/contributors
___
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

[Fedocal, Nuancier] looking for new maintainers

[Michal Konecny]

Hi everybody,

we are currently looking for community members, which will be willing to
take ownership of Fedocal and Nuancier. To see our reasons for this look
at Fedora community blog article [0].

These two applications are part of the Friday with Infra initiative [1],
so you can see what needs to be done for each of these applications. We
are happy to help with those tasks, just let us know how we could help.

What ownership means:
- you will be responsible for codebase (looking for app lifecycle, 
fixing bugs, implementing features)
- you will be admin of the communishift instance (managing openshift 
playbooks, maintaining running pods, deployment of new versions)


What rewards do you get:
- Learning useful and marketable programming skills (ansible, python, 
PostgreSQL)

- Learn how to write, deploy and manage applications in OpenShift!
- Making significant contributions to the Fedora Project community (and 
often others)

- Good feeling for helping Fedora community and Open source world
- A warm glow of accomplishment

On behalf of CPE Team,
Michal
IRC: mkonecny
FAS: zlopez

[0] -
https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/ 


[1] - https://fedoraproject.org/wiki/Infrastructure_2020/Friday_with_Infra
___
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: Drop of PlayOnLinux package (Rawhide)

[Michal Konecny]

I can recommend Lutris, it's really good and I think somebody is working 
on flatpak version for it.


Regards,
Michal Konecny

On 9/10/19 4:11 PM, Frantisek Zatloukal wrote:
Also, I have feeling that Lutris is far superior alternative, at least 
for games :)


On Tue, Sep 10, 2019 at 4:01 PM Michael Cronenworth <mailto:m...@cchtml.com>> wrote:


On 9/10/19 8:35 AM, Miroslav Suchý wrote:
> This will lock me in the Steam only:)

We ship wine-staging, which should handle any Windows game.
___
devel mailing list -- devel@lists.fedoraproject.org
<mailto:devel@lists.fedoraproject.org>
To unsubscribe send an email to
devel-le...@lists.fedoraproject.org
<mailto: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

A Friday with Infra

[Michal Konecny]

Good Morning Everyone,

As you may remember from [1] the CPE team has started categorizing its 
applications into the following categories:


1. We maintain it, we run it
2. We don’t maintain it, we run it
3. We don’t maintain it, we don’t run it
4. We turn it off

In this process we picked the following four applications that we want 
to move from the first category to the third:


 * elections [2]
 * fedocal
 * nuancier
 * badges

However, we do not want to throw code over the wall to anyone, so we’re 
setting up something we called “A Friday with Infra”. The goal is to 
help on-boarding anyone interested in picking up the maintenance of any 
of these apps by taking time on Friday to work on these apps with them.


We have prepared a wiki page describing this proposal, how to get 
involved in it as well as all the work we believe should be done to have 
a smooth hand-over of the applications:

https://fedoraproject.org/wiki/Infrastructure_2020/Friday_with_Infra

Let us know if you have any questions or (even better) want to be 
involved with any of them :)


Michal
– On behalf of the CPE team



[1] 
https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/

[2] elections has actually already found a new maintainer

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

A Friday with Infra

[Michal Konecny]

Good Morning Everyone,

As you may remember from [1] the CPE team has started categorizing its 
applications into the following categories:


1. We maintain it, we run it
2. We don’t maintain it, we run it
3. We don’t maintain it, we don’t run it
4. We turn it off

In this process we picked the following four applications that we want 
to move from the first category to the third:


 * elections [2]
 * fedocal
 * nuancier
 * badges

However, we do not want to throw code over the wall to anyone, so we’re 
setting up something we called “A Friday with Infra”. The goal is to 
help on-boarding anyone interested in picking up the maintenance of any 
of these apps by taking time on Friday to work on these apps with them.


We have prepared a wiki page describing this proposal, how to get 
involved in it as well as all the work we believe should be done to have 
a smooth hand-over of the applications:

https://fedoraproject.org/wiki/Infrastructure_2020/Friday_with_Infra

Let us know if you have any questions or (even better) want to be 
involved with any of them :)


Michal
– On behalf of the CPE team



[1] 
https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/

[2] elections has actually already found a new maintainer

___
devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org

Re: Discussion around app retirements and categorizations by the CPE team

[Michal Konecny]

On 7/22/19 9:04 PM, Jeremy Cline wrote:

Sure, I don't think GitLab is perfect and it has its pain-points.
Working with upstream to make it better for all the communities using it
seems like a much better way to spend our collective time, though.

I totally agree, working on something that will help whole open source 
community will be much better and much more effective than working on 
project that is used by Fedora itself. It will also bring more support 
from open source community itself, because more people using it means 
more developers that want to work on it.


Michal

___
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: Discussion around app retirements and categorizations by the CPE team

[Michal Konecny]

On 7/17/19 10:00 PM, Emmanuel Seyman wrote:

My initial reaction is that the lists of applications in categories 1 and 2
are very short. My second reaction is that this page doesn't sell me that
I should use Python in any business-critical software...
These categories are not complete at all. We didn't go through every 
application we own and put it to specific category. We only got through 
part of our list. It will be long process till we get through whole 
list. In the first CPE blog [0] about changes in our team you can see 
that we are currently maintaining 112 services and we have only 19 
people to do this.


Is release-monitoring.org also maintained by the CPE? It's being broken for
ages and I feel it's a shame it doesn't get more love.
I'm the main maintainer/developer of release-monitoring.org and I 
recently deployed a new version to staging environment, but I'm 
currently busy working with others on Rawhide Gating. I will have talk 
about future of release-monitoring.org on Flock, you can meet me there 
and we could discuss about this or feel free to add any bug to 
release-monitoring.org tracker [1].


There is currently one issue, that is blocking reporting bugs in 
bugzilla, unfortunately this is issue on bugzilla [2] side.


I'm also trying to write blog posts [3] regularly about my work.


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

Michal

[0] - 
https://communityblog.fedoraproject.org/state-of-the-community-platform-engineering-team/

[1] - https://github.com/release-monitoring/anitya/issues
[2] - https://bugzilla.redhat.com/show_bug.cgi?id=1679385
[3] - https://communityblog.fedoraproject.org/tag/release-monitoring-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: Fedora 32 Self-Contained Change proposal: Track Changes in Taiga

[Michal Konecny]

I support this with every vote I have.

mkonecny

On 5/20/19 10:33 PM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/fedora-change-wrangler

= Track Changes in Taiga =
The Motivation for this proposal is to propose using the Taiga
instance at teams.fedoraproject.org for Change processing.
[[User:Bcotton/UsePagureForChanges|Using Pagure]] was previously
proposed for this. The new Change Processing workflow aims to simplify
the process to improve visibility and ease of management.

== Summary ==
The current process allows contributors to propose changes in upcoming
Fedora releases. However, the management of those feature proposals is
cumbersome and requires several manual steps. This introduces more
opportunity for error and reduces the time available to the Change
Wrangler for more valuable contributions to Fedora. In particular, the
current process includes artifacts and discussion in the Fedora Wiki,
on mailing lists, FESCo tickets, Bugzilla tickets, and Docs tickets.

The current process is cumbersome with several  manual steps,this
introduces more opportunity for error and reduces the time available
for the Change Wrangler.
A Cli Tool Written in Python that interacts with Taiga,Pagure and
Bugzilla.Functionality includes
Promoting,announcing,submitting,accepting and updating the changes
across the three platforms and over mailing list.

The new process will consolidate much of the information in
Taiga.Proposed Changes will be submitted as an issue in Taiga. The
description of the Issue will include the content with few exceptions:
* System-Wide or Self-Contained change will be indicated by a binary
in the issue metadata
* Fedora release will be indicated by a milestone in the issue metadata
* Change status will be indicated by a list selection in the issue metadata

== Owner ==
* Name: [[User:Pac23| Manas Mangaonkar]]
* Email: manasmangaon...@gmail.com || pa...@fedoraproject.org
* Name: [[User:Bcotton | Ben Cotton]]
* Email: bcot...@redhat.com


== Detailed Description ==
As Part of GSoC 2019 the fedora-change-wrangler tool will be developed
to smooth out the workflow,reduce Manual Work involved for both the
Contributors and the Change-Wrangler(FPgm). The tool makes it easy by
covering all the functionality required for the process of moving
forward proposals.

The tool will be developed using Python 3.6+ and will interact with
Taiga/Pagure/Bugzilla via their API and the Mailing List via SMTP.
The General Workflow would be :
1. Change Owner opens an issue and fills in the fields. When they are
ready to submit the Change proposal, they set the status to"Ready
for Wrangler".
2. The Change Wrangler (FPgM) reviews the proposal. If it is
incomplete, they set the status back to "New" and inform the Change
Owner of what's needed. If it is ready to process, then...

Functionality covered
1. Promote
* The issue will be promoted to a user story in taiga,copies the
contents of the custom fields from the issue to the user story. Closes
the issue.

2. Announce
* The tool would have the functionality to enable announcing the
change proposal to devel and devel-announce lists using smtp. It will
also automatically change the story status to announced.

3. fesco-submit
* Allowing creation of a new issue in the FESco Pagure repo directly
from the command line.

4. Accept
* Once the changes are accepted the change-wrangler can create a
tracking bug in Bugzilla along with release notes on Pagure.THe status
of the user story is updated to accepted aswell.

5.  Update
* Status can be changed to testable if BZ is "Modified" and to
Complete is BZ is "ON_QA"

6. Creation of Report
* The user can create a report to provide quick view of changes and
their status. It can be in wiki or Html form.

Techstack:
* Python3.6+
* SMTP
* Taiga/Pagure/Bugzilla API's
* Nano/Gedit/Vi ( Inbuilt support to edit text)
* Kerberos(For authentication)

The current sample arg created looks like this [ change-tool convert
--taiga   ] . The advantage of this the Manager
would be able to specify unlimited no of issues to change at once in a
single command using the issue no in taiga to convert to user story.


== Benefit to Fedora ==
The proposed change will make the change-process easier for
everyone.Everyone would be able to see them in one place with
status,id filters. The current wiki process can be bit difficult for
formatting,having defined fields would mean easy access without the
cumbersome wiki edits.

Since changes would be submitted in Issue format on
Taiga,pre-submission discussions would be available thus getting
suggestions/feedback at the first stage itself would be easy for
everyone involved.

== Scope ==
* Proposal owners:
I will be working with the Change-Wrangler(Ben Cotton) throughout the
summer to create this tool from scratch.
* Other developers: N/A (not a System Wide Change)
* Release engineering:(no release engineering impact is expected)
* Trademark approval: N/A (not needed for this Change)

== 

Re: fedora-img-dl: a tool for downloading Fedora iso's and images

[Michal Konecny]

Will this be used by Fedora Media Writer [0]?

[0] - 
https://docs.fedoraproject.org/en-US/quick-docs/creating-and-using-a-live-installation-image/


On 4/15/19 11:22 AM, Jens-Ulrik Petersen wrote:

Hi, I made a small cli tool for downloading Fedora iso's etc.

It can download rawhide, branched, beta, and released isos (eg 
Workstation Live etc), and even WS Live respins (support for spins 
coming later).


You can try it now from 
.


Feedback is welcome.

Jens


ps I am not entirely in love with the name, so if you have suggestions 
for a better one, let me know - note it may also be extended to more 
OSes in the future perhaps.


___
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


___
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 flatpak remote is not GPG verified

[Michal Konecny]

Hi,

I recently started using Fedora flatpak remote in Fedora 30 Silverblue, 
but now I'm facing issue with GPG verification.
I didn't had any issue when installing the application from the remote 
few days ago, but when I'm trying to do `flatpak update` I'm getting 
"Error: Can't pull from untrusted non-gpg verified remote"


Why the flatpak remote is not GPG signed? Or is there another issue?

Regards,
mkonecny
___
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: Fedora, Packaging, Java, and Shrooms

[Michal Konecny]

Hi,

firstly i recommend to use Fedora toolbox [0] for this kind of things on 
Silverblue (it's part of Silverblue already).


Secondly, isn't this what modules are meant for? I'm not sure if there 
is one for JDK on Fedora.


Regards,
Michal Konecny

[0] - https://github.com/debarshiray/toolbox

On 4/11/19 1:40 PM, Ty Young wrote:

Hi,

I'm thinking of switching to Fedora 30 Silverblue(once it comes out of 
beta anyway) from Arch linux. One of the requirements is to be able to 
install, compile from source and easily switch between JDK builds. 
However, Fedora fails to meet these requirements so badly I'm fairly 
certain whoever packaged and approved the various Java RPMs was on 
shrooms(partial offense, sorry but this is nuts).


Confused? Never installed Java in Fedora before? Lets go down the 
rabbit hole together!


Firstly, the java version installed by doing:

rpm-ostree install java

gets you Java 8. I understand that Red Hat is providing support until 
sometime 2023 however I feel it to be much more appropriate that this 
either gives the latest LTS(11 currently) or the newest JDK(12 
currently). Even if still technically support, installing a JRE that 
old isn't likey to be advised. Even in Ubuntu 18.10  you get Java 11.


OK, so just specify the specific versions that you actually need and 
everything will work as it should. No big deal, right? Nope.


alternatives(see: https://fedoraproject.org/wiki/Java), which is 
supposed to allow you to switch between Java versions, flat out 
doesn't work. You tell it to list all alternatives like so:


alternatives --display java

and the command executes without printing anything. Odd. Let's just 
check what's in /usr/lib/jvm for a sanity check:


ls /usr/lib/jvm

java-11-openjdk-11.0.2.7-7.fc30.x86_64
java-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64
java-1.8.0-openjdk-1.8.0.201.b09-6.fc30.x86_64
jre
jre-11
jre-11-openjdk
jre-11-openjdk-11.0.2.7-7.fc30.x86_64
jre-12
jre-12-openjdk
jre-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64
jre-1.8.0
jre-1.8.0-openjdk
jre-1.8.0-openjdk-1.8.0.201.b09-6.fc30.x86_64
jre-openjdk

...

What. I only installed Java 8, Java 11, and Java 12. Installing Java 
on either Ubuntu and Arch doesn't duplicate any JRE/JDK like this.


OK, so lets open it in nautilus:

nautilus /usr/lib/jvm

Those aren't duplicates, all but 3 folders are system links? What? 
This should be the one and only system location for JRE/JDK(s). What's 
going on here? Where do they go?


They go to /etc/alternatives. I guess this is supposed to be how 
alternatives finds alternative JRE/JDK installs. Ubuntu doesn't have 
to do this for update-alternatives nor does Arch's archlinux-java 
script but... OK. This is insanely complicated for no real good reason.


But wait, we aren't done yet because what's being linked to from 
/usr/lib/jvm isn't a file, it's... another system link. Back to the 3 
non system links in /usr/lib/jvm which have horrendously long and 
complex folder names. Is calling them 
java--- not enough?


To top this "what" fest off, the JRE/JDK folders in /etc/alternatives 
aren't even named properly. That is to say,   "jre" is attached to the 
front even if what's being linked is a JDK. Yes, a JDK contains a JRE 
but it's still horribly confusing for no good reason. Like, imagining 
if alternatives did work, does it list duplicate entries for each 
JRE/JDK? For example:


jre_11
java-11-openjdk

which(again) system link to the same JDK install.

What shroom induced insanity is this? Why does alternatives not work?






___
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


___
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: Anitya not working again?

[Michal Konecny]

Hi,

it took some time, but it's done now.

Regards,
mkonecny

On 08/04/19 01:18, Robert-André Mauchin wrote:

On Wednesday, 3 April 2019 16:53:06 CEST Michal Konecny wrote:

Done, you should see new bugs in a few minutes.

mkonecny


May I ask you to do it again for the following list of Python packages?
There are more than 600.

Thanks,

Robert-André



___
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


___
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: Fedora 30 Beta Silverblue Feedback

[Michal Konecny]

On 05/04/19 00:54, Ty Young wrote:


However, there are serious issues with Fedora 30 Beta Silverblue(and 
maybe standard workstation?) with software repositories. On first 
boot, software center will display software and updates(and even be 
downloadable and installable) however and error message will popup 
saying that it can't create/read/writeto a directory(I don't have the 
specific text, sorry). Software repositories are listed in 
gnome-software as expected.



After rebooting all the software repositories are gone and checking 
for updates gives the error message saying that packagekit timedout 
doing a searchbypackagename or something like that. No software 
repositories show up in gnome software anymore. Gnome-software was 
very slow as well.


Silverblue is not using packagekit, so this error must be in 
gnome-software itself. You could report the issue on RedHat bugzilla [0] 
or directly to gnome-software Gitlab [1]



There seems to be an issue with Steam(flatpack edition) where it 
doesn't run at all. It spits out a libGL error saying that:



|libGL error: failed to load driver: swrast|


even with both 64 and 32 bit drivers installed. Am I missing something 
here?


Personally I'm using AMD with Mesa drivers and didn't saw any issue with 
Steam at all. My gaming station is running on Fedora 30 Silverblue Beta 
and Steam in Flatpak without issue. So this seems NVIDIA specific.


If you want help from Silverblue team you could ask them in #silverblue 
channel on freenode, on Discourse [2] or as far as I know they are using 
Fedora desktop mailing list.


mkonecny

[0] - https://bugzilla.redhat.com/
[1] - https://gitlab.gnome.org/GNOME/gnome-software
[2] - https://discussion.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://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


___
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: Anitya not working again?

[Michal Konecny]

Done, you should see new bugs in a few minutes.

mkonecny

On 03/04/19 12:56, Michal Konecny wrote:
It should be easy to do it, with the script I have. I just need to do 
some adjustments.


mkonecny

On 02/04/19 20:36, Igor Gnatenko wrote:
Michal, can you do it for all packages with ecosystem crates.io 
<http://crates.io>?


On Tue, Apr 2, 2019 at 8:04 PM Michal Konecny <mailto:mkone...@redhat.com>> wrote:


I refreshed every project on the list (deleted latest version
that will
be retrieved again in next check, which is done every hour). You
should
already see new bugs in Bugzilla for the projects on this list.

mkonecny

On 29/03/19 10:45, Michal Konecny wrote:
>
>
> On 29/03/19 10:31, Robert-André Mauchin wrote:
>> On Friday, 29 March 2019 09:30:31 CET Michal Konecny wrote:
>>>>
>>>> Could you send me the list of projects you added? I will
manually
>>>> refresh them.
>>>
>>> I was right, there is missing message call in API code for
adding new
>>> package mapping. I created issue for it here
>>> https://github.com/release-monitoring/anitya/issues/760
>>>
>>> I will fix this in future release, but for the existing
projects I can
>>> only refresh them manually. So if you provide me a list of
projects you
>>> added, I will do it.
>>>
>> I didn't keep a list of which one I added, or which one were
already
>> there.
>> I can only give you a list of all packages which went to the
script:
>>
>> golang-apache-thrift
>> golang-bazil-fuse
>> golang-bitbucket-kardianos-osext
>> golang-bitbucket-ww-goautoneg
>> golang-cloud-google
>> golang-contrib-opencensus-exporter
>> golang-contrib-opencensus-exporter-ocagent
>> golang-deepin-dbus-factory
>> golang-deepin-go-lib
>> golang-dmitri-shuralyov-html-belt
>> golang-dmitri-shuralyov-route-github
>> golang-dmitri-shuralyov-state
>> golang-etcd-bbolt
>> golang-github-10gen-escaper
>> golang-github-10gen-openssl
>> golang-github-3rf-mongo-lint
>> golang-github-a8m-tree
>> golang-github-abbot-go-http-auth
>> golang-github-aclements-gg
>> golang-github-aclements-moremath
>> golang-github-AdRoll-goamz
>> golang-github-aead-chacha20
>> golang-github-aead-poly1305
>> golang-github-agl-ed25519
>> golang-github-ajstarks-svgo
>> golang-github-akrennmair-gopcap
>> golang-github-alcortesm-tgz
>> golang-github-alecthomas-assert
>> golang-github-alecthomas-chroma
>> golang-github-alecthomas-colour
>> golang-github-alecthomas-kingpin
>> golang-github-alecthomas-kong
>> golang-github-alecthomas-repr
>> golang-github-alecthomas-template
>> golang-github-alecthomas-units
>> golang-github-alexcesaro-quotedprintable-v3
>> golang-github-anacrolix-envpprof
>> golang-github-anacrolix-missinggo
>> golang-github-anacrolix-tagflag
>> golang-github-andybalholm-cascadia
>> golang-github-anmitsu-shlex
>> golang-github-appc-spec
>> golang-github-armon-circbuf
>> golang-github-armon-gomdb
>> golang-github-armon-go-metrics
>> golang-github-armon-go-proxyproto
>> golang-github-armon-go-radix
>> golang-github-asaskevich-govalidator
>> golang-github-AudriusButkevicius-cli
>> golang-github-AudriusButkevicius-go-nat-pmp
>> golang-github-AudriusButkevicius-kcp-go
>> golang-github-AudriusButkevicius-pfilter
>> golang-github-auth0-go-jwt-middleware
>> golang-github-aws-aws-sdk-go
>> golang-github-axgle-mahonia
>> golang-github-azure-autorest
>> golang-github-Azure-azure-sdk-for-go
>> golang-github-azure-pipeline
>> golang-github-azure-storage-blob
>> golang-github-beevik-ntp
>> golang-github-benbjohnson-clock
>> golang-github-beorn7-perks
>> golang-github-bep-debounce
>> golang-github-bep-gitmap
>> golang-github-bep-inflect
>> golang-github-bep-tocss
>> golang-github-bgentry-go-netrc
>> golang-github-bgentry-speakeasy
>> golang-github-billziss-gh-cgofuse
>> golang-github-bitly-go-simplejson
>> golang-github-bitly-simplejson
>> golang-github-bkaradzic-go-lz4
>> golang-github-blang-semver
>> golang-github-bmizerany-assert
>> golang-github-bmizerany-pat
>> golang-

Re: Anitya not working again?

[Michal Konecny]

It should be easy to do it, with the script I have. I just need to do 
some adjustments.


mkonecny

On 02/04/19 20:36, Igor Gnatenko wrote:
Michal, can you do it for all packages with ecosystem crates.io 
<http://crates.io>?


On Tue, Apr 2, 2019 at 8:04 PM Michal Konecny <mailto:mkone...@redhat.com>> wrote:


I refreshed every project on the list (deleted latest version that
will
be retrieved again in next check, which is done every hour). You
should
already see new bugs in Bugzilla for the projects on this list.

mkonecny

On 29/03/19 10:45, Michal Konecny wrote:
>
>
> On 29/03/19 10:31, Robert-André Mauchin wrote:
>> On Friday, 29 March 2019 09:30:31 CET Michal Konecny wrote:
>>>>
>>>> Could you send me the list of projects you added? I will manually
>>>> refresh them.
>>>
>>> I was right, there is missing message call in API code for
adding new
>>> package mapping. I created issue for it here
>>> https://github.com/release-monitoring/anitya/issues/760
>>>
>>> I will fix this in future release, but for the existing
projects I can
>>> only refresh them manually. So if you provide me a list of
projects you
>>> added, I will do it.
>>>
>> I didn't keep a list of which one I added, or which one were
already
>> there.
>> I can only give you a list of all packages which went to the
script:
>>
>> golang-apache-thrift
>> golang-bazil-fuse
>> golang-bitbucket-kardianos-osext
>> golang-bitbucket-ww-goautoneg
>> golang-cloud-google
>> golang-contrib-opencensus-exporter
>> golang-contrib-opencensus-exporter-ocagent
>> golang-deepin-dbus-factory
>> golang-deepin-go-lib
>> golang-dmitri-shuralyov-html-belt
>> golang-dmitri-shuralyov-route-github
>> golang-dmitri-shuralyov-state
>> golang-etcd-bbolt
>> golang-github-10gen-escaper
>> golang-github-10gen-openssl
>> golang-github-3rf-mongo-lint
>> golang-github-a8m-tree
>> golang-github-abbot-go-http-auth
>> golang-github-aclements-gg
>> golang-github-aclements-moremath
>> golang-github-AdRoll-goamz
>> golang-github-aead-chacha20
>> golang-github-aead-poly1305
>> golang-github-agl-ed25519
>> golang-github-ajstarks-svgo
>> golang-github-akrennmair-gopcap
>> golang-github-alcortesm-tgz
>> golang-github-alecthomas-assert
>> golang-github-alecthomas-chroma
>> golang-github-alecthomas-colour
>> golang-github-alecthomas-kingpin
>> golang-github-alecthomas-kong
>> golang-github-alecthomas-repr
>> golang-github-alecthomas-template
>> golang-github-alecthomas-units
>> golang-github-alexcesaro-quotedprintable-v3
>> golang-github-anacrolix-envpprof
>> golang-github-anacrolix-missinggo
>> golang-github-anacrolix-tagflag
>> golang-github-andybalholm-cascadia
>> golang-github-anmitsu-shlex
>> golang-github-appc-spec
>> golang-github-armon-circbuf
>> golang-github-armon-gomdb
>> golang-github-armon-go-metrics
>> golang-github-armon-go-proxyproto
>> golang-github-armon-go-radix
>> golang-github-asaskevich-govalidator
>> golang-github-AudriusButkevicius-cli
>> golang-github-AudriusButkevicius-go-nat-pmp
>> golang-github-AudriusButkevicius-kcp-go
>> golang-github-AudriusButkevicius-pfilter
>> golang-github-auth0-go-jwt-middleware
>> golang-github-aws-aws-sdk-go
>> golang-github-axgle-mahonia
>> golang-github-azure-autorest
>> golang-github-Azure-azure-sdk-for-go
>> golang-github-azure-pipeline
>> golang-github-azure-storage-blob
>> golang-github-beevik-ntp
>> golang-github-benbjohnson-clock
>> golang-github-beorn7-perks
>> golang-github-bep-debounce
>> golang-github-bep-gitmap
>> golang-github-bep-inflect
>> golang-github-bep-tocss
>> golang-github-bgentry-go-netrc
>> golang-github-bgentry-speakeasy
>> golang-github-billziss-gh-cgofuse
>> golang-github-bitly-go-simplejson
>> golang-github-bitly-simplejson
>> golang-github-bkaradzic-go-lz4
>> golang-github-blang-semver
>> golang-github-bmizerany-assert
>> golang-github-bmizerany-pat
>> golang-github-bmizerany-perks
>> golang-github-boltdb-bolt
>> golang-github-boombuler-

Re: Anitya not working again?

[Michal Konecny]

I refreshed every project on the list (deleted latest version that will 
be retrieved again in next check, which is done every hour). You should 
already see new bugs in Bugzilla for the projects on this list.


mkonecny

On 29/03/19 10:45, Michal Konecny wrote:



On 29/03/19 10:31, Robert-André Mauchin wrote:

On Friday, 29 March 2019 09:30:31 CET Michal Konecny wrote:


Could you send me the list of projects you added? I will manually
refresh them.


I was right, there is missing message call in API code for adding new
package mapping. I created issue for it here
https://github.com/release-monitoring/anitya/issues/760

I will fix this in future release, but for the existing projects I can
only refresh them manually. So if you provide me a list of projects you
added, I will do it.

I didn't keep a list of which one I added, or which one were already 
there.

I can only give you a list of all packages which went to the script:

golang-apache-thrift
golang-bazil-fuse
golang-bitbucket-kardianos-osext
golang-bitbucket-ww-goautoneg
golang-cloud-google
golang-contrib-opencensus-exporter
golang-contrib-opencensus-exporter-ocagent
golang-deepin-dbus-factory
golang-deepin-go-lib
golang-dmitri-shuralyov-html-belt
golang-dmitri-shuralyov-route-github
golang-dmitri-shuralyov-state
golang-etcd-bbolt
golang-github-10gen-escaper
golang-github-10gen-openssl
golang-github-3rf-mongo-lint
golang-github-a8m-tree
golang-github-abbot-go-http-auth
golang-github-aclements-gg
golang-github-aclements-moremath
golang-github-AdRoll-goamz
golang-github-aead-chacha20
golang-github-aead-poly1305
golang-github-agl-ed25519
golang-github-ajstarks-svgo
golang-github-akrennmair-gopcap
golang-github-alcortesm-tgz
golang-github-alecthomas-assert
golang-github-alecthomas-chroma
golang-github-alecthomas-colour
golang-github-alecthomas-kingpin
golang-github-alecthomas-kong
golang-github-alecthomas-repr
golang-github-alecthomas-template
golang-github-alecthomas-units
golang-github-alexcesaro-quotedprintable-v3
golang-github-anacrolix-envpprof
golang-github-anacrolix-missinggo
golang-github-anacrolix-tagflag
golang-github-andybalholm-cascadia
golang-github-anmitsu-shlex
golang-github-appc-spec
golang-github-armon-circbuf
golang-github-armon-gomdb
golang-github-armon-go-metrics
golang-github-armon-go-proxyproto
golang-github-armon-go-radix
golang-github-asaskevich-govalidator
golang-github-AudriusButkevicius-cli
golang-github-AudriusButkevicius-go-nat-pmp
golang-github-AudriusButkevicius-kcp-go
golang-github-AudriusButkevicius-pfilter
golang-github-auth0-go-jwt-middleware
golang-github-aws-aws-sdk-go
golang-github-axgle-mahonia
golang-github-azure-autorest
golang-github-Azure-azure-sdk-for-go
golang-github-azure-pipeline
golang-github-azure-storage-blob
golang-github-beevik-ntp
golang-github-benbjohnson-clock
golang-github-beorn7-perks
golang-github-bep-debounce
golang-github-bep-gitmap
golang-github-bep-inflect
golang-github-bep-tocss
golang-github-bgentry-go-netrc
golang-github-bgentry-speakeasy
golang-github-billziss-gh-cgofuse
golang-github-bitly-go-simplejson
golang-github-bitly-simplejson
golang-github-bkaradzic-go-lz4
golang-github-blang-semver
golang-github-bmizerany-assert
golang-github-bmizerany-pat
golang-github-bmizerany-perks
golang-github-boltdb-bolt
golang-github-boombuler-barcode
golang-github-bradfitz-gomemcache
golang-github-bradfitz-http2
golang-github-bradfitz-iter
golang-github-bradfitz-smtpd
golang-github-briandowns-spinner
golang-github-bruth-assert
golang-github-bufio-v1
golang-github-buger-jsonparser
golang-github-bugsnag-bugsnag-go
golang-github-bugsnag-panicwrap
golang-github-BurntSushi-freetype-go
golang-github-BurntSushi-graphics-go
golang-github-burntsushi-locker
golang-github-BurntSushi-toml
golang-github-BurntSushi-toml-test
golang-github-BurntSushi-xgb
golang-github-BurntSushi-xgbutil
golang-github-calmh-du
golang-github-calmh-luhn
golang-github-calmh-xdr
golang-github-ccding-go-stun
golang-github-cenkalti-backoff
golang-github-census-instrumentation-opencensus-proto
golang-github-cespare-xxhash
golang-github-chaseadamsio-goorgeous
golang-github-cheekybits-is
golang-github-cheggaaa-pb
golang-github-chmduquesne-rollinghash
golang-github-chrismalek-oktasdk-go
golang-github-chzyer-logex
golang-github-chzyer-test
golang-github-circonus-labs-circonus-gometrics
golang-github-circonus-labs-circonusllhist
golang-github-client9-gospell
golang-github-cloudflare
golang-github-cloudfoundry-incubator-candiedyaml
golang-github-cockroachdb-cmux
golang-github-cockroachdb-cockroach-go
golang-github-codahale-aesnicheck
golang-github-codahale-hdrhistogram
golang-github-codegangsta-cli
golang-github-codegangsta-negroni
golang-github-collectd-go-collectd
golang-github-coreos-bbolt
golang-github-coreos-gexpect
golang-github-coreos-go-etcd
golang-github-coreos-go-iptables
golang-github-coreos-go-log
golang-github-coreos-go-oidc
golang-github-coreos-go-semver
golang-github-coreos-go-systemd
golang-github-coreos-pkg
golang-github-cosiner

Re: Anitya not working again?

[Michal Konecny]

On 29/03/19 10:31, Robert-André Mauchin wrote:

On Friday, 29 March 2019 09:30:31 CET Michal Konecny wrote:


Could you send me the list of projects you added? I will manually
refresh them.


I was right, there is missing message call in API code for adding new
package mapping. I created issue for it here
https://github.com/release-monitoring/anitya/issues/760

I will fix this in future release, but for the existing projects I can
only refresh them manually. So if you provide me a list of projects you
added, I will do it.


I didn't keep a list of which one I added, or which one were already there.
I can only give you a list of all packages which went to the script:

golang-apache-thrift
golang-bazil-fuse
golang-bitbucket-kardianos-osext
golang-bitbucket-ww-goautoneg
golang-cloud-google
golang-contrib-opencensus-exporter
golang-contrib-opencensus-exporter-ocagent
golang-deepin-dbus-factory
golang-deepin-go-lib
golang-dmitri-shuralyov-html-belt
golang-dmitri-shuralyov-route-github
golang-dmitri-shuralyov-state
golang-etcd-bbolt
golang-github-10gen-escaper
golang-github-10gen-openssl
golang-github-3rf-mongo-lint
golang-github-a8m-tree
golang-github-abbot-go-http-auth
golang-github-aclements-gg
golang-github-aclements-moremath
golang-github-AdRoll-goamz
golang-github-aead-chacha20
golang-github-aead-poly1305
golang-github-agl-ed25519
golang-github-ajstarks-svgo
golang-github-akrennmair-gopcap
golang-github-alcortesm-tgz
golang-github-alecthomas-assert
golang-github-alecthomas-chroma
golang-github-alecthomas-colour
golang-github-alecthomas-kingpin
golang-github-alecthomas-kong
golang-github-alecthomas-repr
golang-github-alecthomas-template
golang-github-alecthomas-units
golang-github-alexcesaro-quotedprintable-v3
golang-github-anacrolix-envpprof
golang-github-anacrolix-missinggo
golang-github-anacrolix-tagflag
golang-github-andybalholm-cascadia
golang-github-anmitsu-shlex
golang-github-appc-spec
golang-github-armon-circbuf
golang-github-armon-gomdb
golang-github-armon-go-metrics
golang-github-armon-go-proxyproto
golang-github-armon-go-radix
golang-github-asaskevich-govalidator
golang-github-AudriusButkevicius-cli
golang-github-AudriusButkevicius-go-nat-pmp
golang-github-AudriusButkevicius-kcp-go
golang-github-AudriusButkevicius-pfilter
golang-github-auth0-go-jwt-middleware
golang-github-aws-aws-sdk-go
golang-github-axgle-mahonia
golang-github-azure-autorest
golang-github-Azure-azure-sdk-for-go
golang-github-azure-pipeline
golang-github-azure-storage-blob
golang-github-beevik-ntp
golang-github-benbjohnson-clock
golang-github-beorn7-perks
golang-github-bep-debounce
golang-github-bep-gitmap
golang-github-bep-inflect
golang-github-bep-tocss
golang-github-bgentry-go-netrc
golang-github-bgentry-speakeasy
golang-github-billziss-gh-cgofuse
golang-github-bitly-go-simplejson
golang-github-bitly-simplejson
golang-github-bkaradzic-go-lz4
golang-github-blang-semver
golang-github-bmizerany-assert
golang-github-bmizerany-pat
golang-github-bmizerany-perks
golang-github-boltdb-bolt
golang-github-boombuler-barcode
golang-github-bradfitz-gomemcache
golang-github-bradfitz-http2
golang-github-bradfitz-iter
golang-github-bradfitz-smtpd
golang-github-briandowns-spinner
golang-github-bruth-assert
golang-github-bufio-v1
golang-github-buger-jsonparser
golang-github-bugsnag-bugsnag-go
golang-github-bugsnag-panicwrap
golang-github-BurntSushi-freetype-go
golang-github-BurntSushi-graphics-go
golang-github-burntsushi-locker
golang-github-BurntSushi-toml
golang-github-BurntSushi-toml-test
golang-github-BurntSushi-xgb
golang-github-BurntSushi-xgbutil
golang-github-calmh-du
golang-github-calmh-luhn
golang-github-calmh-xdr
golang-github-ccding-go-stun
golang-github-cenkalti-backoff
golang-github-census-instrumentation-opencensus-proto
golang-github-cespare-xxhash
golang-github-chaseadamsio-goorgeous
golang-github-cheekybits-is
golang-github-cheggaaa-pb
golang-github-chmduquesne-rollinghash
golang-github-chrismalek-oktasdk-go
golang-github-chzyer-logex
golang-github-chzyer-test
golang-github-circonus-labs-circonus-gometrics
golang-github-circonus-labs-circonusllhist
golang-github-client9-gospell
golang-github-cloudflare
golang-github-cloudfoundry-incubator-candiedyaml
golang-github-cockroachdb-cmux
golang-github-cockroachdb-cockroach-go
golang-github-codahale-aesnicheck
golang-github-codahale-hdrhistogram
golang-github-codegangsta-cli
golang-github-codegangsta-negroni
golang-github-collectd-go-collectd
golang-github-coreos-bbolt
golang-github-coreos-gexpect
golang-github-coreos-go-etcd
golang-github-coreos-go-iptables
golang-github-coreos-go-log
golang-github-coreos-go-oidc
golang-github-coreos-go-semver
golang-github-coreos-go-systemd
golang-github-coreos-pkg
golang-github-cosiner-argv
golang-github-cosmos72-gomacro
golang-github-cpu-goacmedns
golang-github-cpuguy83-go-md2man
golang-github-cryptix-wav
golang-github-cznic-b
golang-github-cznic-fileutil
golang-github-cznic-golex
golang-github-cznic-internal
golang-github-cznic-lex
golang

Re: Anitya not working again?

[Michal Konecny]

On 29/03/19 08:40, Michal Konecny wrote:



On 28/03/19 20:14, Robert-André Mauchin wrote:

On Thursday, 28 March 2019 19:38:30 CET Michal Konecny wrote:

I found out what is wrong, you created the project without Fedora
mapping, so the first version was retrieved without knowing how this is
packaged in Fedora. But I see, that the mapping was added later, but 
the

message about the mapping wasn't send by Anitya. Did you added the
mapping using API, maybe the message is not published when the mapping
is changed using API?

Yes I first created the project without Fedora mapping. Then added 
the mapping

in a second time, all using the API.



I can still see few golang updates coming through recently:
golang-github-hashicorp-mdns - [0]
golang-github-pierrec-lz4 - [1]

Could you check what exactly is missing from the projects you added. 
You

could check the latest messages from the-new-hotness in [2]

[0] -
https://apps.fedoraproject.org/datagrepper/id?id=2019-79474d61-c5f9-4b07-866 


3-7ea15f434774_raw=true=extra-large

  [1] -
https://apps.fedoraproject.org/datagrepper/id?id=2019-e171f618-4c2e-4a27-825 


0-ebe8deec6b26_raw=true=extra-large

  [2] -
https://apps.fedoraproject.org/datagrepper/raw?category=hotness=259200 


0

For my example, the message says:

hotness.update.drop the-new-hotness saw an update for stats, but 
release-

monitoring.org doesn't know what that project is called in Fedora land

https://apps.fedoraproject.org/datagrepper/id?id=2019-40749965-2805-4e33-a037-cbbd4a6283bb_raw=true=extra-large

Doesn't it send the notification if the mapping is added afterward?
It should, but it looks like it doesn't send any if the mapping is 
added using API. Probably missing call to publish message in API. I 
will check this.


Could you send me the list of projects you added? I will manually 
refresh them.


I was right, there is missing message call in API code for adding new 
package mapping. I created issue for it here 
https://github.com/release-monitoring/anitya/issues/760


I will fix this in future release, but for the existing projects I can 
only refresh them manually. So if you provide me a list of projects you 
added, I will do it.


mkonecny


___
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

___
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

___
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: Anitya not working again?

[Michal Konecny]

On 28/03/19 20:14, Robert-André Mauchin wrote:

On Thursday, 28 March 2019 19:38:30 CET Michal Konecny wrote:

I found out what is wrong, you created the project without Fedora
mapping, so the first version was retrieved without knowing how this is
packaged in Fedora. But I see, that the mapping was added later, but the
message about the mapping wasn't send by Anitya. Did you added the
mapping using API, maybe the message is not published when the mapping
is changed using API?


Yes I first created the project without Fedora mapping. Then added the mapping
in a second time, all using the API.



I can still see few golang updates coming through recently:
golang-github-hashicorp-mdns - [0]
golang-github-pierrec-lz4 - [1]

Could you check what exactly is missing from the projects you added. You
could check the latest messages from the-new-hotness in [2]

[0] -
https://apps.fedoraproject.org/datagrepper/id?id=2019-79474d61-c5f9-4b07-866
3-7ea15f434774_raw=true=extra-large

  [1] -

https://apps.fedoraproject.org/datagrepper/id?id=2019-e171f618-4c2e-4a27-825
0-ebe8deec6b26_raw=true=extra-large

  [2] -

https://apps.fedoraproject.org/datagrepper/raw?category=hotness=259200
0

For my example, the message says:

hotness.update.drop the-new-hotness saw an update for stats, but release-
monitoring.org doesn't know what that project is called in Fedora land

  
https://apps.fedoraproject.org/datagrepper/id?id=2019-40749965-2805-4e33-a037-cbbd4a6283bb_raw=true=extra-large

Doesn't it send the notification if the mapping is added afterward?
It should, but it looks like it doesn't send any if the mapping is added 
using API. Probably missing call to publish message in API. I will check 
this.


Could you send me the list of projects you added? I will manually 
refresh them.


mkonecny


___
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

___
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