Unresponsive packagers: suanand and vponcova

[Pierre-Yves Chibon]

Good Morning Everyone,

We have been emailing daily the following users to notify that the email they
have set in FAS does not correspond to a valid bugzilla account.
This is a requirement for Fedora packagers.

Does someone know how to contact them?

suanand - emailed since April 5th

suanand is maintainer of rpms/gettext
suanand is main admin of rpms/php-gettext-gettext
  rpms/php-gettext-gettext co-maintainers: @petersen
suanand has a bugzilla override on rpms/php-gettext-gettext
suanand is main admin of rpms/php-gettext-languages
  rpms/php-gettext-languages co-maintainers: @petersen
suanand has a bugzilla override on rpms/php-gettext-languages
suanand is maintainer of rpms/python-polib
suanand is maintainer of rpms/python-tinydb
suanand is maintainer of rpms/translate-toolkit
suanand is maintainer of rpms/transtats-cli
suanand is maintainer of rpms/zanata-python-client

vponcova - emailed since February 26th

vponcova is maintainer of rpms/anaconda
vponcova is maintainer of rpms/pykickstart
vponcova is maintainer of rpms/python-blivet
vponcova is maintainer of rpms/python-dasbus


Thanks for your help,

Pierre
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: convert everything to rpmautospec?

[Pierre-Yves Chibon]

On Thu, Apr 11, 2024 at 09:18:09AM +0200, Ondrej Mosnáček wrote:
> On Wed, 10 Apr 2024 at 16:30, Pierre-Yves Chibon  wrote:
> [...]
> > Let's look at it in another way: would you say that the people who leaved 
> > in the
> > 14th century were liars for saying that the earth is flat?
> > No, they just didn't know.
> 
> Off-topic and not really affecting the validity of your point, but the
> idea that people in the 14th century / Middle Ages generally believed
> that the earth was flat is a myth. I recently read about it in the
> book "Fake History: 101 Things that Never Happened" by Jo Teeuwisse
> (great book, BTW!), but also Wikipedia happens to have a decent
> article about it: https://en.wikipedia.org/wiki/Myth_of_the_flat_Earth

I stand corrected, maybe "we believed earth was the center of the universe"
would have worked better?
Or something related to medicine?

Anyway, as you said, the point was: context changes and that doesn't make
what someone said a lie.


Thanks,
Pierre
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: convert everything to rpmautospec?

[Pierre-Yves Chibon]

On Mon, Apr 08, 2024 at 02:55:36PM +0200, Emmanuel Seyman wrote:
> * Zbigniew Jędrzejewski-Szmek [08/04/2024 09:02] :
> >
> > Well, you and Kevin see "salami tactics" (whatever that may be),
> 
> FTR, I have no idea what "salami tactics" is.
> 
> > while I see normal engineering practice: some new idea is hatched,
> > it's implemented and used narrowly, them it's applied by default
> > and more widely, and possibly at the end previous methods are
> > deprecated.
> 
> This sounds acceptable but is not at all how these changes are proposed.
> 
> An proposal is made, stating explicity that it will be opt-in or target
> a subset of the target audience and never even suggesting that the scope
> might one day be expanded.
> 
> It is accepted based on that premise and, after a while, changes are
> made to make the change default or opt-out, leaving the people who would
> not have accepted it had they known they would be forced to use it with
> no recourse.
> 
> This is unfriendly (thus violating one of Fedora's core principles) at
> best and deceitful at worst.
> 
> > The alternative would be to have "grand plans" where we decide that
> > some technology will be used by default and mandatory before we deploy
> > it widely and get feedback.
> 
> Another alternative would be not lie to the target audience by
> initially claiming that the change is opt-in. Yet another alternative
> would be to not go back on this claim.

There is one flaw in the reasoning here, as one of the original person behind
rpmautospec (with Nils who arguably has done more for it than me), you can see
that neither of us are involved in this proposal nor this discussion.

So it's a bit unfair to qualify that this was/is a lie and that the goal from
the get go when the change is being asked/proposed by someone else.

So no, it was not a lie, the goal was to make it opt-in. It is still the agreed
behavior and if someone proposes to change it, it's still not a lie. It would be
a lie if at that time, I would have thought: "this is going to be awesome and
we'll end up forcing it but for now I won't present it as such".

Let's look at it in another way: would you say that the people who leaved in the
14th century were liars for saying that the earth is flat?
No, they just didn't know.
Things/context changes and with this our knowledge or opinions. That doesn't
mean where we started from was a lie, it was just a different time/context.


So please, express your feeling in another way and don't use that word.

Thanks,
Pierre
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [Pierre-Yves Chibon] Unresponsive packagers: nknazeko

[Pierre-Yves Chibon]

On Tue, Feb 13, 2024 at 11:20:59AM +0100, Pierre-Yves Chibon wrote:
> 
> On Sun, Feb 11, 2024 at 10:44:18PM +0100, Vit Mojzis wrote:
> > Nikola left Red Hat and hence changed the email address in FAS. I'm
> > guessing that only her Red Hat email was tied to a BZ account.
> > I'll try and let her know. Do I understand correctly that she just needs
> > to create a new BZ account using the email address in FAS?
> 
> That's correct, she either need to create a bugzilla account associated with 
> the
> email she uses in FAS, or fill in the "bugzilla email" field of her FAS 
> account
> with the email of her bugzilla account.

Hey Vit,

Just out of curiosity, have you heard back from her?
From our side the issue still seems to be present.

Thanks,
Pierre
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [Pierre-Yves Chibon] Unresponsive packagers: nknazeko

[Pierre-Yves Chibon]

On Sun, Feb 11, 2024 at 10:44:18PM +0100, Vit Mojzis wrote:
>  Hello Pierre,

Hi Vit,

Sorry for the late reply

> Nikola left Red Hat and hence changed the email address in FAS. I'm
> guessing that only her Red Hat email was tied to a BZ account.
> I'll try and let her know. Do I understand correctly that she just needs
> to create a new BZ account using the email address in FAS?

That's correct, she either need to create a bugzilla account associated with the
email she uses in FAS, or fill in the "bugzilla email" field of her FAS account
with the email of her bugzilla account.

Thanks for your help!

Pierre


> On 2/9/24 15:06, Petr Lautrbach wrote:
> Good Morning Everyone,
> 
> Since November 1st, we have been emailing daily the following user to notify
> that the email they have set in FAS does not correspond to a valid bugzilla
> account.
> This is a requirement for Fedora packagers.
> 
> Does someone know how to contact nknazeko?
> 
> nknazeko is maintainer of rpms/selinux-policy
> 
> 
> Thanks for your help,
> 
> Pierre
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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
>  End of forwarded message 
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Unresponsive packagers: yangrr

[Pierre-Yves Chibon]

Good Morning Everyone,

Since January 17th, we have been emailing daily the following user to notify
that the email they have set in FAS does not correspond to a valid bugzilla
account.
This is a requirement for Fedora packagers.

Does someone know how to contact yangrr?

yangrr is watching rpms/0x
yangrr is watching rpms/hstr
yangrr is maintainer of rpms/kexec-tools


Thanks for your help,

Pierre
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Unresponsive packagers: nknazeko

[Pierre-Yves Chibon]

Good Morning Everyone,

Since November 1st, we have been emailing daily the following user to notify
that the email they have set in FAS does not correspond to a valid bugzilla
account.
This is a requirement for Fedora packagers.

Does someone know how to contact nknazeko?

nknazeko is maintainer of rpms/selinux-policy


Thanks for your help,

Pierre
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Synching user database from Fedora IPA to pagure

[Pierre-Yves Chibon]

On Tue, Nov 28, 2023 at 10:13:35AM +, Mattia Verga via devel wrote:
> I'd like to start writing a script to synch users/groups from Fedora IPA 
> to pagure.io and src.fp.o: both pagure.io and src.fp.o logins are based 
> on Fedora accounts, but the Pagure user database is only updated when a 
> user login in Pagure.

I know this thread has been closed for a while and I'm pretty sure that info has
been passed onto the other place where this discussion evolved, but for the
posterity I'm adding it here as well:

pagure.io does not rely on groups from FAS, only src.fp.o does.
Groups in pagure.io are entirely managed within pagure.io, just the user account
are coming from FAS.
src.fp.p on the other hand is the opposite, all the groups are managed from FAS*
and membership is indeed synced upon login.

So now that it's here for the posterity, we can go back to what we were doing :)

Thanks,
Pierre




*well, an admin needs to create it on src.fp.o with the same name and then it'll
be added to the list of groups pagure asks upon login.
So if you want sig-foo, you create sig-foo in FAS and add its users there, then
you create sig-foo in src.fp.o and membership will sync over time.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Unresponsive packagers: kubo

[Pierre-Yves Chibon]

Good Morning Everyone,

Since June 30th, we have been emailing daily the following user to notify
that the email they have set in FAS does not correspond to a valid bugzilla
account.
This is a requirement for Fedora packagers.

Does someone know how to contact kubo?

kubo is watching rpms/golang-github-docopt-docopt-go
kubo is maintainer of rpms/perl-Array-Utils
kubo is maintainer of rpms/perl-Astro-FITS-CFITSIO
kubo is maintainer of rpms/perl-Crypt-Rijndael
kubo is maintainer of rpms/perl-DBD-MariaDB
kubo is maintainer of rpms/perl-DBD-Mock
kubo is maintainer of rpms/perl-DateTime-Event-Recurrence
kubo is maintainer of rpms/perl-DateTime-Set
kubo is maintainer of rpms/perl-DateTimeX-Easy
kubo is maintainer of rpms/perl-Digest-Perl-MD5
kubo is maintainer of rpms/perl-Email-Valid
kubo is maintainer of rpms/perl-Excel-Writer-XLSX
kubo is maintainer of rpms/perl-Exception-Class-TryCatch
kubo is maintainer of rpms/perl-File-Path-Tiny
kubo is maintainer of rpms/perl-HTML-Table
kubo is maintainer of rpms/perl-HTML-Template-Pro
kubo is maintainer of rpms/perl-HTTP-Body
kubo is maintainer of rpms/perl-Heap
kubo is maintainer of rpms/perl-MooseX-Aliases
kubo is maintainer of rpms/perl-MooseX-NonMoose
kubo is maintainer of rpms/perl-MooseX-Types-Path-Class
kubo is maintainer of rpms/perl-PDL
kubo is maintainer of rpms/perl-SQL-Abstract
kubo is maintainer of rpms/perl-Statistics-Descriptive
kubo is maintainer of rpms/perl-Test-Spec


Thanks for your help,

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: The new Change discussion process is painful

[Pierre-Yves Chibon]

On Wed, Sep 13, 2023 at 10:46:04AM +0200, Vít Ondruch wrote:
> 
> Dne 13. 09. 23 v 9:08 Remi Collet napsal(a):
> > Le 13/09/2023 à 08:09, Adam Williamson a écrit :
> > > On Wed, 2023-09-13 at 05:51 +0200, Kevin Kofler via devel wrote:
> > > > Hi,
> > > > 
> > > > it is really a pain that the Change discussion is now hidden in
> > > > a web forum
> > > > behind a web link, instead of happening right here in this
> > > > mailing list. It
> > > > was promised that Discourse would NOT replace the mailing lists,
> > > > but that is
> > > > effectively no longer the case. Can this "Discourse for Change
> > > > discussion"
> > > > experiment please be stopped? It has no advantages and only adds
> > > > a useless
> > > > layer of indirection.
> > > 
> > > I don't really understand what you mean. AFAICT, every Change that has
> > > been announced at
> > > https://discussion.fedoraproject.org/c/project/changes/89 has also been
> > > announced at
> > > https://lists.fedoraproject.org/archives/list/devel-announce%40lists.fedoraproject.org/
> > > 
> > > , so nothing has been replaced.
> > 
> > Sadly it seems there is some email issues
> > 
> > For a few days, tons of messages are lost
> > so, I also don't receive any of the recent change announcements
> 
> 
> If nothing else, the announcements were previously send to devel-announce
> with devel in CC, while the CC is not included anymore. IOW can we have
> devel back in CC, please?

I'm pretty sure devel is subscribed to devel-announce, so email sent to
devel-announce will/should land on devel as well.


Pierre


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

Re: PDC replacement proposal

[Pierre-Yves Chibon]

On Tue, Sep 05, 2023 at 11:35:19AM -0700, Kevin Fenzi wrote:
> On Mon, Sep 04, 2023 at 04:51:22PM +0200, Tomas Hrcka wrote:
> > Hello all, it took us a few years but we are finally getting rid of the PDC
> > project. Thanks to the ARC research we identified use cases in our tooling
> > and proposed solution.
> > 
> > The essential functionalities currently provided by PDC will be
> > re-implemented in other applications within our release infrastructure, as
> > there are no immediate plans for their replacement and are currently
> > maintained
> > 
> > This work is anticipated to span several months for completion. However,
> > before we embark on this endeavor,
> > 
> > we would like to proactively share our proposed solution with all of you
> > and gather your valuable feedback.
> > 
> > Below, we outline our strategy to preserve the core functionality of PDC by
> > leveraging existing applications within our ecosystem.
> > 
> > Current uses of PDC:
> > 
> > Currently, we rely on the Package Database (PDC) for various data
> > management tasks, including:
> > 
> > 
> >1.
> > 
> >Critical Path Package Tracking: Bodhi leverages PDC to track packages on
> >the critical path.
> 
> As Adam mentioned this is already not in pdc. ;) 
> 
> >2.
> > 
> >Retirement of Packages and Service Level Agreements (SLAs): PDC assists
> >in managing the retirement of packages and their associated SLAs.
> 
> Yeah. The super big one is that its queried from a git commit hook for
> all src.fedoraproject.org git commits. Right now if pdc is down, no one
> could commit anything. 
> 
> 
> >3.
> > 
> >Metadata for Nightly Composes: Our Release Engineering and Fedora
> >Quality Assurance teams rely on PDC for metadata related to nightly
> >composes.
> > 
> > 
> > More info on the usage can be found here:
> > https://fedora-arc.readthedocs.io/en/latest/pdc/users.html
> 
> mass rebuild of modules can be dropped. ;) 
> 
> fedscm-admin is now the scm requests toddler. It still uses pdc tho
> of course. 
>  
> > Specific Endpoints in Use:
> 
> ...snip...
> 
> > Upcoming Changes
> > 
> > Bodhi:
> > 
> > Bodhi will assume responsibility for the following tasks, reducing our
> > reliance on PDC:
> > 
> > /rest_api/v1/releases/: Bodhi will now manage release-related data.
> 
> Do note that bodhi still has a window after we are 'go' for a relase
> where it thinks it's released, but it's not yet. We probibly need to
> address this if we are moving this to bodhi.
> 
> > /rest_api/v1/component-branches/: Specifically, Bodhi will handle the
> > critical-path flag.
> 
> Already done. 
> 
> ...snip...
> > 
> > Pagure-dist-git:
> > 
> > Pagure-dist-git will take over several responsibilities from PDC, including:
> > 
> > /rest_api/v1/product-versions
> > 
> > /rest_api/v1/global-components
> > 
> > /rest_api/v1/component-branches/
> > 
> > /rest_api/v1/component-branch-slas/
> > 
> > Pagure already has a robust database of global components (repositories)
> > and product versions (repository branches).
> > 
> > It utilizes the PDC API to query component branches when a package is
> > retired, and an auxiliary table in Pagure-dist-git will store the reasons
> > for orphaning these components.
> 
> So, I know this will work... but it means more closely tying ourselves
> to pagure-dist-git. ;( 
> 
> With modules going out of the picture, most branches just have the
> release cycle of the fedora or rhel release they are based on, so
> couldn't we just default that somewhere?

In the pkgdb time, the EOL status was basically simply computed from the release
status, ie: what we still have at: 
https://admin.fedoraproject.org/pkgdb/api/collections
(looks like we should fix the branchname in that json)
but we could just go back to this :)


Pierre


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

Re: Update on DNF05 in Fedora

[Pierre-Yves Chibon]

On Thu, Jul 27, 2023 at 11:27:37AM -0700, Kevin Fenzi wrote:
> On Thu, Jul 27, 2023 at 08:41:42AM -0400, Samantha Bueno wrote:
> > I want to close on a positive note and commend my team for the incredible
> > amount of hard work they have poured into this project thus far, as well as
> > people we've been collaborating with and who have been testing and offering
> > feedback. We have more test days planned and will continue to operate
> > transparently as we proceed through development.
> 
> I wanted to repeat what I noted in the FESCo meeting:
> 
> I'd like to also thank the dnf5 team. It can't be easy to retarget something 
> you
> were working on so long. My thanks for being honest about the status and
> realistic about timeframes and needed work. Kudos!

I'd like to second that, these decisions are never easy to take and thank you
for having the courage of making it.


Pierre


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

Non-responsive packagers: sbluhm, shaneallcroft

[Pierre-Yves Chibon]

Good Morning Everyone,

The packagers listed here have been receiving a daily email asking them to
either adjust their bugzilla or their FAS account so the email address in FAS
matches an existing bugzilla account.

Having a bugzilla account is mandatory per:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account

- sbluhm contacted since January 11th 2023
sbluhm is maintainer of rpms/apache-commons-digester
sbluhm has a bugzilla override on rpms/apache-commons-digester
sbluhm is maintainer of rpms/disruptor
sbluhm has a bugzilla override on rpms/disruptor
sbluhm is maintainer of rpms/ecj
sbluhm is maintainer of rpms/jakarta-activation
sbluhm is maintainer of rpms/jakarta-servlet
sbluhm has a bugzilla override on rpms/jakarta-servlet
sbluhm is maintainer of rpms/jaxb-api
sbluhm is maintainer of rpms/jdom
sbluhm is maintainer of rpms/mercurial
sbluhm is maintainer of rpms/mxparser
sbluhm has a bugzilla override on rpms/mxparser
sbluhm is main admin of rpms/nekohtml
  rpms/nekohtml co-maintainers: @fnasser, @mizdebsk
sbluhm has a bugzilla override on rpms/nekohtml
sbluhm is maintainer of rpms/openpgm
sbluhm is maintainer of rpms/perl-Mail-RFC822-Address
sbluhm is maintainer of rpms/python-debian
sbluhm is maintainer of rpms/python-geoip2
sbluhm is maintainer of rpms/python-maxminddb
sbluhm is maintainer of rpms/python-ws4py
sbluhm is maintainer of rpms/snakeyaml
sbluhm has a bugzilla override on rpms/snakeyaml
sbluhm is maintainer of rpms/xmlpull
sbluhm has a bugzilla override on rpms/xmlpull
sbluhm is main admin of rpms/xpp3
  rpms/xpp3 co-maintainers: @jerboaa, @mizdebsk
sbluhm has a bugzilla override on rpms/xpp3
sbluhm is maintainer of rpms/xstream
sbluhm has a bugzilla override on rpms/xstream


- shaneallcroft contacted since January 11th 2023
shaneallcroft is main admin of rpms/pyplane
shaneallcroft has a bugzilla override on rpms/pyplane


Does anyone know how to contact them?


Thanks,

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Nonresponsive maintainers ( was Re: Red Hat Bugzilla mail FAS field is now handled correctly by Bugzilla sync scripts )

[Pierre-Yves Chibon]

On Thu, Jan 26, 2023 at 05:10:15PM -0800, Kevin Fenzi wrote:
> On Tue, Jan 17, 2023 at 02:49:10PM +0100, Michal Konecny wrote:
> > 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.
> 
> Hello everyone. 
> 
> After this we still have 4 users who's bugzilla email does not exist. :( 
> 
> They are: 

> npmccallum

Nathaniel has been on the list for 2 or 3 months at this point. I've been
wanting to start the non-responsive process a while back but got a bit lazy to
look at the exact date when we started sending him emails :(

Thanks for starting this Kevin!

Pierre


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

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Pierre-Yves Chibon]

On Thu, Oct 13, 2022 at 10:36:52AM +0300, Panu Matilainen wrote:
> On 10/12/22 17:47, Stephen Smoogen wrote:
> > 
> > 
> > On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming  > > wrote:
> > 
> > On 10/12/22 08:59, Stephen Smoogen wrote:
> >  > Maybe call it the Fedora Update Manager 'FUM' ?
> > 
> > Unless we're going to call it RUM when it makes its way into RHEL, that
> > name may not be the best choice :-)
> > 
> > 
> > Well Red Hat shipped the Yellowdog Update Manager for 2 releases so I am
> > sure they can go with FUM or RUM (RPM Update Manager)..
> 
> RPM Update Manager, an easily pronouncable and distro agnostic acronym which
> even makes sense. Now that would be a hard sell...

Depends, once the age question is resolved, buying RUM should be fairly straight
forward :-p


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Inactive provenpackagers to be removed from group

[Pierre-Yves Chibon]

On Thu, Aug 11, 2022 at 02:07:08PM -0400, Ben Cotton wrote:
> In accordance with FESCo policy[1], the following provenpackagers will
> be submitted for removal in two weeks based on a lack of Koji builds
> submitted in the last six months. If you received this directly, you
> can reply off-list to indicate you should still be in the
> provenpackager group.
> 
> Note that removal from this group is not a "punishment" or a lack of
> appreciation for the work you have done. The intent of the process is
> to ensure contributors with distro-wide package privileges are still
> active and responsive. This process is done regularly at the branch
> point in each release.
> 
> [1] 
> https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/#_maintaining_provenpackager_status
> 
> Checked 140 provenpackagers
> The following 14 provenpackagers have not submitted a Koji build since
> at least 2022-02-03 00:00:00:
> pingou

I have indeed done very little packaging lately and in the spirit of only having
the level of access that you need, I'm fine with being removed from the
provenpackager group.
I just hope that if I need this level of access in the future it won't be
painful to ask for them again :)


Thanks for doing this!

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Non-responsive packagers: benzea

[Pierre-Yves Chibon]

On Thu, Jul 21, 2022 at 11:30:07AM +0200, Benjamin Berg wrote:
> Hi,
> 
> sorry for not dealing with this earlier. I was somewhat out for a
> while, and didn't give the mail much significance.
> 
> What happened is that I'll be leaving Red Hat. As a first step, I
> changed my FAS email address while explicitly keeping my Red Hat
> address for bugzilla for now.
> 
> I thought that just having two different addresses on
> accounts.fedorproject.org would work, but I suppose I would also need
> to add myself to
> https://pagure.io/fedora-infra/ansible/raw/main/f/roles/openshift-apps/toddlers/templates/email_overrides.toml
> 
> Either way, I think I'll just fix it by creating the corresponding
> bugzilla account so that the two addresses are in sync again.

Thanks for addressing this! :)


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

Re: Non-responsive packagers: benzea

[Pierre-Yves Chibon]

On Mon, Jul 18, 2022 at 10:12:55AM +0200, Tomáš Popela wrote:
> Hi Pierre,
> 
> Is the subject right? It talks about "michaelanguskelly", but the queries
> are for Benjamin (benzea). I can talk to Benjamin if needed (already
> pointed him at this thread just in case).

Hi Tomáš,

Thanks for pointing this out, that's what I get for re-using an old email as
template :(

The correct user is benzea indeed.

Thanks for pointing him to this thread!


Pierre


> On Mon, Jul 18, 2022 at 9:59 AM Pierre-Yves Chibon 
> wrote:
> 
> > Good Morning Everyone,
> >
> > The packagers listed here have been receiving a daily email asking them to
> > either adjust their bugzilla or their FAS account so the email address in
> > FAS
> > matches an existing bugzilla account.
> >
> > Having a bugzilla account is mandatory per:
> >
> > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account
> >
> > - benzea contacted since June 23rd 2022
> > benzea is maintainer of rpms/bolt
> > benzea is main admin of rpms/devtodo
> > benzea has a bugzilla override on rpms/devtodo
> > benzea is main admin of rpms/fprintd
> > benzea has a bugzilla override on rpms/fprintd
> > benzea is main admin of rpms/fwts
> > benzea has a bugzilla override on rpms/fwts
> > benzea is maintainer of rpms/gamemode
> > benzea is main admin of rpms/gnome-network-displays
> > benzea has a bugzilla override on rpms/gnome-network-displays
> > benzea is main admin of rpms/libfprint
> > benzea has a bugzilla override on rpms/libfprint
> > benzea is maintainer of rpms/libusb
> > benzea is maintainer of rpms/libusb-compat-0.1
> > benzea is maintainer of rpms/libusb1
> > benzea is main admin of rpms/libusbx
> > benzea has a bugzilla override on rpms/libusbx
> > benzea is main admin of rpms/thermald
> > benzea has a bugzilla override on rpms/thermald
> > benzea is maintainer of rpms/umockdev
> > benzea is maintainer of rpms/upower
> > benzea is main admin of rpms/uresourced
> > benzea has a bugzilla override on rpms/uresourced
> >
> >
> >
> > Does anyone know how to contact them?
> >
> >
> > Thanks,
> >
> > Pierre
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/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

Non-responsive packagers: michaelanguskelly

[Pierre-Yves Chibon]

Good Morning Everyone,

The packagers listed here have been receiving a daily email asking them to
either adjust their bugzilla or their FAS account so the email address in FAS
matches an existing bugzilla account.

Having a bugzilla account is mandatory per:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account

- benzea contacted since June 23rd 2022
benzea is maintainer of rpms/bolt
benzea is main admin of rpms/devtodo
benzea has a bugzilla override on rpms/devtodo
benzea is main admin of rpms/fprintd
benzea has a bugzilla override on rpms/fprintd
benzea is main admin of rpms/fwts
benzea has a bugzilla override on rpms/fwts
benzea is maintainer of rpms/gamemode
benzea is main admin of rpms/gnome-network-displays
benzea has a bugzilla override on rpms/gnome-network-displays
benzea is main admin of rpms/libfprint
benzea has a bugzilla override on rpms/libfprint
benzea is maintainer of rpms/libusb
benzea is maintainer of rpms/libusb-compat-0.1
benzea is maintainer of rpms/libusb1
benzea is main admin of rpms/libusbx
benzea has a bugzilla override on rpms/libusbx
benzea is main admin of rpms/thermald
benzea has a bugzilla override on rpms/thermald
benzea is maintainer of rpms/umockdev
benzea is maintainer of rpms/upower
benzea is main admin of rpms/uresourced
benzea has a bugzilla override on rpms/uresourced



Does anyone know how to contact them?


Thanks,

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Once again, more than 8 days delayed notifications

[Pierre-Yves Chibon]

On Sat, Jul 09, 2022 at 09:36:14AM -0400, Stephen Smoogen wrote:
> On Sat, 9 Jul 2022 at 09:25, Ralf Corsépius  wrote:
> 
> > Hi,
> >
> > I thought the notification delay mess was fixed. Apparently, I was wrong.
> >
> >
> 
> No, I believe the service which is behind these emails is called FMN. It is
> very fragile for multiple reasons where it falls over for different reasons
> all the time. It is the reason why it is on the top of being replaced by
> CPE in this quarter (aka by October-ish). 

Just a quick note, I doubt the app will be re-written and deploy in a single
quarter, I expect this to be more a multi-months effort. So while it has the top
of the priority list for CPE to work on, it'll still take a little time before
we see a v4 (we've already restructured it 3 times).

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Once again, more than 8 days delayed notifications

[Pierre-Yves Chibon]

On Sat, Jul 09, 2022 at 05:16:55PM +0200, Ralf Corsépius wrote:
> 
> 
> Am 09.07.22 um 15:36 schrieb Stephen Smoogen:
> > 
> > 
> > On Sat, 9 Jul 2022 at 09:25, Ralf Corsépius  > > wrote:
> > 
> > Hi,
> > 
> > I thought the notification delay mess was fixed. Apparently, I was
> > wrong.
> > 
> > 
> > 
> > No, I believe the service which is behind these emails is called FMN. It
> > is very fragile for multiple reasons where it falls over for different
> > reasons all the time. It is the reason why it is on the top of being
> > replaced by CPE in this quarter (aka by October-ish). Until that
> > happens, please be aware that these notifications are likely to come in
> > bursts as things go up and down. I would also suggest that turning off
> > as many notifications as you can would help the load as one of the
> > largest email problems Fedora Infrastructure has is the many people who
> > have turned on getting email on a lot of events.
> 
> Why don't you turn this stuff off globally and send the guys behind it back
> to the drawing board?
> 
> In its present shape it's just dysfunctional and not helpful at all.

It is very much self-service, so you can easily turn off the notifications for
your account if you wish to:
https://apps.fedoraproject.org/notifications


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [RFC] Build tag in RPM: from NVR to NVRB

[Pierre-Yves Chibon]

On Tue, Jun 21, 2022 at 12:27:57AM +0200, Fabio Valentini wrote:
> On Tue, Jun 21, 2022 at 12:15 AM Neal Gompa  wrote:
> >
> > On Mon, Jun 20, 2022 at 3:48 PM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > >
> > > On Sat, Jun 18, 2022 at 01:05:31PM +0200, Aleksandra Fedorova wrote:
> > > > The most visible impact of the proposal would be the filename change:
> > > >
> > > >   Current: dnf-4.9.0-12.fc36.noarch.rpm
> > > >   Proposed: dnf-4.9.0-12.fc36.34897715.noarch.rpm
> > >
> > > The history of development of rpm and the ecosystem has shown that
> > > modifications that are visibile at the level of the output binary rpm
> > > have a long implementation tail for the ecosystem. In particular, if
> > > we allow add the build-number information, many many consumers will
> > > need to adjust for this, from trivial things like regexps to match
> > > '%dist.rpm' in the filename to complicated things that extract and
> > > make use of the version field. So if we want to add a new feature
> > > here, a much strong justification why what we have already is not
> > > enough would need to be provided.
> > >
> >
> > This is already something people have to expect, since our existing
> > policy permits a tailing number and it is used for various purposes.
> 
> Well, it's complicated.
> 
> There's currently a 100% foolproof way to parse NEVRs into their
> components, because there are *always* two "-" separators (when
> counting from the end) that separate "name", "epoch:version", and
> "release" (i.e. you can do nevr.rsplit("-", 2) in Python, and you get
> 100% correct results for 100% of packages in Fedora repositories).

That is already broken today with modules where the stream which is included in
the name can have '-' in them.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Non-responsive packagers: michaelanguskelly

[Pierre-Yves Chibon]

Good Morning Everyone,

The packagers listed here have been receiving a daily email asking them to
either adjust their bugzilla or their FAS account so the email address in FAS
matches an existing bugzilla account.

Having a bugzilla account is mandatory per:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account

- michaelanguskelly contacted since March 29th
michaelanguskelly is maintainer of rpms/python-oauthlib


Does anyone know how to contact them?


Thanks,

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Can't fedpkg new-sources (403)

[Pierre-Yves Chibon]

On Wed, Mar 16, 2022 at 01:45:52PM -0400, Neal Becker wrote:
>On Wed, Mar 16, 2022 at 1:38 PM Neal Becker <[1]ndbeck...@gmail.com>
>wrote:
> 
>  I believe it is failing on the line:
>    File "/usr/lib/python3.10/site-packages/pyrpkg/lookaside.py", line
>  298, in upload
>      if self.remote_file_exists(name, filename, hash):
>    File "/usr/lib/python3.10/site-packages/pyrpkg/lookaside.py", line
>  259, in remote_file_exists
>      self.raise_upload_error(status)
>  So maybe the file already exists in the cache?  But then, sources has
>  not been updated, and if I try 
>  fedpkg local it will attempt to build the old version 1.8.1, not the new
>  1.9.0.
> 
>OK, so unuran-1.9.0.tar.gz already exists in the cache.  So I had to
>manually update sources by running
>md5sum unuran-1.9.0.tar.gz, which luckily I just guessed.  Now everything
>seems to be working fine.

Also, we no longer use md5sum in our lookaside cache by default, but sha512, so
you may have more chances using that algorithm :)


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Do we have any policy for disabling inactive users

[Pierre-Yves Chibon]

On Sat, Feb 12, 2022 at 10:29:54AM +, Mattia Verga via devel wrote:
> Il 11/02/22 20:24, Kevin Fenzi ha scritto:
> > On Fri, Feb 11, 2022 at 11:33:13AM +, Mattia Verga via devel wrote:
> >> Il 11/02/22 12:20, Florian Weimer ha scritto:
> >>> * Mattia Verga via devel:
> >>>
>  Il 11/02/22 10:41, Miro Hrončok ha scritto:
> > On 11. 02. 22 10:12, Mattia Verga via devel wrote:
> >> Where are those 2543 packagers come from? src.fedoraproject.org only
> >> shows 1787 users in the packager group:
> >>
> >> https://src.fedoraproject.org/api/0/group/packager
> > They might have never even logged into src.fedoraproject.org
> >
>  \o/ So, I think those 756 can be added to the removal list as well...
> >>> Why?  Isn't logging into src.fedoraproject.org optional from a workflow
> >>> perspective?
> >>>
> >> I suppose "logging" means that src.fedoraproject.org has no knowledge
> >> about that user... so that user never pushed any commit / PR / comment.
> > I don't think just pushing a commit would log you into pagure. You need
> > to login to the web interface for it to create/refresh your account.
> > PR's and comments would definitely, but just pushing commits would not.
> >
> mmm... I suppose that, even if a user only uses CLI to push a commit,
> pagure needs to verify its credentials and associates the commit to the
> user in the web UI... so pagure MUST know about the user in its database.

I was going to say that only packagers have a shell account on src.fp.o and
should thus be allowed to push, but I've quickly checked the code and you are
correct, in order to determine if an user is allowed to push to a specific
package, we check their access level in pagure's database (ie: are they a
package admin? committer? collaborator?), so I don't think a packager that has
never logged in on src.fp.o would be allowed to push a commit.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Do we have any policy for disabling inactive users

[Pierre-Yves Chibon]

On Fri, Feb 11, 2022 at 11:24:24AM -0800, Kevin Fenzi wrote:
> On Fri, Feb 11, 2022 at 11:33:13AM +, Mattia Verga via devel wrote:
> > Il 11/02/22 12:20, Florian Weimer ha scritto:
> > > * Mattia Verga via devel:
> > >
> > >> Il 11/02/22 10:41, Miro Hrončok ha scritto:
> > >>> On 11. 02. 22 10:12, Mattia Verga via devel wrote:
> >  Where are those 2543 packagers come from? src.fedoraproject.org only
> >  shows 1787 users in the packager group:
> > 
> >  https://src.fedoraproject.org/api/0/group/packager
> > >>> They might have never even logged into src.fedoraproject.org
> > >>>
> > >> \o/ So, I think those 756 can be added to the removal list as well...
> > > Why?  Isn't logging into src.fedoraproject.org optional from a workflow
> > > perspective?
> > >
> > I suppose "logging" means that src.fedoraproject.org has no knowledge
> > about that user... so that user never pushed any commit / PR / comment.
> 
> I don't think just pushing a commit would log you into pagure. You need
> to login to the web interface for it to create/refresh your account.
> PR's and comments would definitely, but just pushing commits would not.
> 
> > Have I misunderstood? Does src.fedoraproject.org not recognize a user to
> > be in the packager group if they never logged in and only pushed things
> > by CLI?
> 
> I think that is indeed the case, but I'm not 100% sure. 
> Perhaps Pingou could chime in on this. 

Correct on both accounts. src.fp.o has no idea who someone is until they log in
via the user-interface, so the same thing applies for group membership.


Pierre


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

Re: Non-responsive packagers: lef, msehnout, shaneallcroft

[Pierre-Yves Chibon]

On Mon, Feb 07, 2022 at 10:47:11AM +0100, Fabio Valentini wrote:
> On Mon, Feb 7, 2022 at 9:58 AM Pierre-Yves Chibon  wrote:
> >
> > Good Morning Everyone,
> >
> > The packagers listed here have been receiving a daily email asking them to
> > either adjust their bugzilla or their FAS account so the email address in 
> > FAS
> > matches an existing bugzilla account.
> >
> > Having a bugzilla account is mandatory per:
> > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account
> >
> > - msehnout contacted since December 15th
> >
> > msehnout is watching rpms/bind
> > msehnout is watching rpms/bind99
> > msehnout is maintainer of rpms/ipcalc
> > msehnout is watching rpms/libpcap
> > msehnout is maintainer of rpms/osbuild
> > msehnout is maintainer of rpms/osbuild-composer
> > msehnout is watching rpms/pure-ftpd
> > msehnout is watching rpms/tcpdump
> > msehnout is watching rpms/vsftpd
> > msehnout is watching rpms/wireshark
> >
> > (I will be opening a FESCo ticket for msehnout right now as this is the 
> > second
> > email sent to the devel list)
> >
> > - shaneallcroft contacted since January 28th
> >
> > shaneallcroft is main admin of rpms/pyplane
> > shaneallcroft has a bugzilla override on rpms/pyplane
> >
> > - lef contacted since January 22nd
> >
> > (lef's package list is quite large, so I'm putting it at the very end of 
> > this
> > email)
> 
> We already went through the non-responsive maintainer process for lef in 2019:
> https://pagure.io/fesco/issue/2160
> 
> Looks like the script to remove them from packages either hasn't been
> around, or hasn't been run

Ok, thanks for the info, I'll run the script for lef then :)

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Non-responsive packagers: lef, msehnout, shaneallcroft

[Pierre-Yves Chibon]

Good Morning Everyone,

The packagers listed here have been receiving a daily email asking them to
either adjust their bugzilla or their FAS account so the email address in FAS
matches an existing bugzilla account.

Having a bugzilla account is mandatory per:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account

- msehnout contacted since December 15th

msehnout is watching rpms/bind
msehnout is watching rpms/bind99
msehnout is maintainer of rpms/ipcalc
msehnout is watching rpms/libpcap
msehnout is maintainer of rpms/osbuild
msehnout is maintainer of rpms/osbuild-composer
msehnout is watching rpms/pure-ftpd
msehnout is watching rpms/tcpdump
msehnout is watching rpms/vsftpd
msehnout is watching rpms/wireshark

(I will be opening a FESCo ticket for msehnout right now as this is the second
email sent to the devel list)

- shaneallcroft contacted since January 28th

shaneallcroft is main admin of rpms/pyplane
shaneallcroft has a bugzilla override on rpms/pyplane

- lef contacted since January 22nd

(lef's package list is quite large, so I'm putting it at the very end of this
email)


Does anyone know how to contact them?


Thanks,

Pierre


lef is maintainer of rpms/HikariCP
lef has a bugzilla override on rpms/HikariCP
lef is maintainer of rpms/PyXB
lef has a bugzilla override on rpms/PyXB
lef is maintainer of rpms/aesh
lef has a bugzilla override on rpms/aesh
lef is maintainer of rpms/airline
lef has a bugzilla override on rpms/airline
lef is maintainer of rpms/antlr-maven-plugin
lef has a bugzilla override on rpms/antlr-maven-plugin
lef is maintainer of rpms/antlr3
lef is maintainer of rpms/antlr4
lef has a bugzilla override on rpms/antlr4
lef is watching rpms/apache-commons-csv
lef has a bugzilla override on rpms/apache-commons-csv
lef is maintainer of rpms/apache-james-project
lef has a bugzilla override on rpms/apache-james-project
lef is watching rpms/apache-mime4j
lef has a bugzilla override on rpms/apache-mime4j
lef is maintainer of rpms/apache-poi
lef has a bugzilla override on rpms/apache-poi
lef is maintainer of rpms/apiviz
lef has a bugzilla override on rpms/apiviz
lef is maintainer of rpms/aries-blueprint-annotation-api
lef has a bugzilla override on rpms/aries-blueprint-annotation-api
lef is maintainer of rpms/aries-blueprint-api
lef has a bugzilla override on rpms/aries-blueprint-api
lef is maintainer of rpms/aries-blueprint-core
lef has a bugzilla override on rpms/aries-blueprint-core
lef is maintainer of rpms/aries-blueprint-parser
lef has a bugzilla override on rpms/aries-blueprint-parser
lef is maintainer of rpms/aries-proxy-api
lef has a bugzilla override on rpms/aries-proxy-api
lef is maintainer of rpms/aries-proxy-impl
lef has a bugzilla override on rpms/aries-proxy-impl
lef is maintainer of rpms/aries-quiesce-api
lef has a bugzilla override on rpms/aries-quiesce-api
lef is maintainer of rpms/aries-util
lef has a bugzilla override on rpms/aries-util
lef is maintainer of rpms/arquillian-core
lef has a bugzilla override on rpms/arquillian-core
lef is maintainer of rpms/artemis
lef has a bugzilla override on rpms/artemis
lef is maintainer of rpms/artemis-wildfly-integration
lef has a bugzilla override on rpms/artemis-wildfly-integration
lef is maintainer of rpms/atool
lef has a bugzilla override on rpms/atool
lef is watching rpms/auto
lef has a bugzilla override on rpms/auto
lef is maintainer of rpms/avro
lef has a bugzilla override on rpms/avro
lef is watching rpms/bean-validation-api
lef has a bugzilla override on rpms/bean-validation-api
lef is maintainer of rpms/bytelist
lef has a bugzilla override on rpms/bytelist
lef is watching rpms/c3p0
lef is maintainer of rpms/castor
lef has a bugzilla override on rpms/castor
lef is maintainer of rpms/checkstyle
lef is maintainer of rpms/classmate
lef has a bugzilla override on rpms/classmate
lef is maintainer of rpms/cli-parser
lef has a bugzilla override on rpms/cli-parser
lef is maintainer of rpms/conakry-fonts
lef has a bugzilla override on rpms/conakry-fonts
lef is maintainer of rpms/cookcc
lef has a bugzilla override on rpms/cookcc
lef is maintainer of rpms/cryptacular
lef has a bugzilla override on rpms/cryptacular
lef is watching rpms/crypto-policies
lef is maintainer of rpms/cxf
lef has a bugzilla override on rpms/cxf
lef is maintainer of rpms/cxf-build-utils
lef has a bugzilla override on rpms/cxf-build-utils
lef is maintainer of rpms/cxf-xjc-utils
lef has a bugzilla override on rpms/cxf-xjc-utils
lef is maintainer of rpms/deltaspike
lef has a bugzilla override on rpms/deltaspike
lef is watching rpms/derby
lef has a bugzilla override on rpms/derby
lef is watching rpms/disruptor
lef is maintainer of rpms/easymock3
lef has a bugzilla override on rpms/easymock3
lef is maintainer of rpms/eclipse
lef is maintainer of rpms/eclipse-filesystem
lef has a bugzilla override on rpms/eclipse-filesystem
lef is maintainer of rpms/eclipselink
lef has a bugzilla override on rpms/eclipselink
lef is maintainer of 

Re: Action Required: Bugzilla - API Authentication changes

[Pierre-Yves Chibon]

On Tue, Feb 01, 2022 at 01:41:01PM +0100, Miro Hrončok wrote:
> On 01. 02. 22 13:37, Fabio Valentini wrote:
> > Hi Miro,
> > 
> > Thanks for forwarding this announcement.
> > Apparently the talk about "improving communication between RHBZ and
> > the Fedora Project" has not born fruit yet. ;)
> 
> Well the announcement was public, I recommend subscribing to
> https://listman.redhat.com/mailman/listinfo/bugzilla-announce-list if you
> interact with bugzilla a lot.
> 
> > Do we know if any of our tools and scripts that interact with RHBZ
> > will get broken by this?
> > I assume you have an eye on at least some of the releng scripts (FTI,
> > FTBFS, etc.).
> 
> I will check. I think it's all broken.
> 
> > But what about fedora-review? fedora-create-review? The tool that
> > syncs assignees from dist-git to RHBZ?
> 
> No idea.

Most of these tools are written in python and as the email says, the most recent
version of python-bugzilla works fine (which is already in Fedora and EPEL -
stable).

So as long as your systems are up to date, it should be somewhat transparent.


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

Re: Non-responsive packagers: anoopcs, gtiwari, msehnout, sebix, vanessa_kris

[Pierre-Yves Chibon]

On Fri, Jan 21, 2022 at 02:31:57PM +0530, Anoop C S wrote:
> On Thu, 2022-01-20 at 09:57 +0100, Pierre-Yves Chibon wrote:
> > Good Morning Everyone,
> > 
> > The packagers listed here have been receiving a daily email asking
> > them to
> > either adjust their bugzilla or their FAS account so the email
> > address in FAS
> > matches an existing bugzilla account.
> > 
> > Having a bugzilla account is mandatory per:
> > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account
> > 
> > - anoopcs contacted since November 27th
> > 
> > anoopcs is maintainer of rpms/glusterfs
> > anoopcs is main admin of rpms/glusterfs-coreutils
> > anoopcs has a bugzilla override on rpms/glusterfs-coreutils
> > anoopcs is maintainer of rpms/richacl
> > anoopcs is maintainer of rpms/samba
> > anoopcs is watching rpms/socket_wrapper
> 
> I am aware and was ignoring it based on the reply I got for the ticket
> raised[1] on the exact same issue. I also wanted to know where the
> ongoing work for making use of bugzilla field in FAS(I made another
> comment after ticket got closed) is being tracked. May be issue
> #9863[2]?

That's a question I do not have the answer to.

> Very recent request(via email) for bugzilla email validation gave me an
> impression that its finally gonna happen.

It is being worked on but it is not ready yet (I expect that it will be
announced once it is).

> If not, how important it is to match both(FAS and bugzilla) email
> addresses at this point? Or is it a requirement now to have same email
> address to get the work completed? Sorry, I am little confused.

It is important as it breaks the sync from dist-git to bugzilla and for the
entire component (package), so it impacts you as well as potentially any other
co-maintainers or watchers of the packages you are linked to.

Currently there are two ways to get this sync working:
- either have a valid bugzilla account corresponding to your main FAS email
- add an override to manually map your main FAS email to your bugzilla account
  in:
  
https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openshift-apps/toddlers/templates/email_overrides.toml


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

Re: Non-responsive packagers: anoopcs, gtiwari, msehnout, sebix, vanessa_kris

[Pierre-Yves Chibon]

On Thu, Jan 20, 2022 at 10:04:25AM +, Ankur Sinha wrote:
> Hello,
> 
> > - vanessa_kris contacted since December 10th
> > 
> > vanessa_kris is main admin of rpms/python-git-changelog
> > vanessa_kris has a bugzilla override on rpms/python-git-changelog
> > vanessa_kris is main admin of rpms/python-glymur
> > vanessa_kris has a bugzilla override on rpms/python-glymur
> 
> Vanessa had to create a new user because the `_` doesn't work for
> fedorapeople.org:
> 
> https://pagure.io/fedora-infrastructure/issue/10377#comment-767776
> 
> So, they've now created vanessakris (without the `_`) and we've given
> the new account admin access on all these packages, and disabled the
> older account.
> 
> I guess we should've used the older account to orphan these first? I can
> ask Vanessa to do that now.

Looks to be fixed this morning, many thanks for handling this :)


Pierre


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

Non-responsive packagers: anoopcs, gtiwari, msehnout, sebix, vanessa_kris

[Pierre-Yves Chibon]

Good Morning Everyone,

The packagers listed here have been receiving a daily email asking them to
either adjust their bugzilla or their FAS account so the email address in FAS
matches an existing bugzilla account.

Having a bugzilla account is mandatory per:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account

- anoopcs contacted since November 27th

anoopcs is maintainer of rpms/glusterfs
anoopcs is main admin of rpms/glusterfs-coreutils
anoopcs has a bugzilla override on rpms/glusterfs-coreutils
anoopcs is maintainer of rpms/richacl
anoopcs is maintainer of rpms/samba
anoopcs is watching rpms/socket_wrapper

- gtiwari contacted since January 14th

gtiwari is main admin of rpms/bluez
gtiwari has a bugzilla override on rpms/bluez

- msehnout contacted since December 15th

msehnout is watching rpms/bind
msehnout is watching rpms/bind99
msehnout is maintainer of rpms/ipcalc
msehnout is watching rpms/libpcap
msehnout is maintainer of rpms/osbuild
msehnout is maintainer of rpms/osbuild-composer
msehnout is watching rpms/pure-ftpd
msehnout is watching rpms/tcpdump
msehnout is watching rpms/vsftpd
msehnout is watching rpms/wireshark

- sebix contacted since December 4th

sebix is maintainer of rpms/lockfile-progs
sebix has a bugzilla override on rpms/lockfile-progs
sebix is maintainer of rpms/logcheck
sebix has a bugzilla override on rpms/logcheck

- vanessa_kris contacted since December 10th

vanessa_kris is main admin of rpms/python-git-changelog
vanessa_kris has a bugzilla override on rpms/python-git-changelog
vanessa_kris is main admin of rpms/python-glymur
vanessa_kris has a bugzilla override on rpms/python-glymur


Does anyone know how to contact them?


Thanks,

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Workflow and other problems with the Fedora container infrastructure

[Pierre-Yves Chibon]

On Sun, Jan 16, 2022 at 08:42:30AM -0500, Josh Boyer wrote:
>On Sat, Jan 15, 2022, 6:57 PM Kevin Fenzi <[1]ke...@scrye.com> wrote:
> 
>  On Thu, Jan 13, 2022 at 02:14:19PM -0500, Neal Gompa wrote:
>  >
>  > One of the things that has recently happened in the Koji space is the
>  > addition of a kiwi-build task to build images using the KIWI tool[1].
>  >
>  > KIWI supports building all kinds of operating system images, including
>  > OCI containers. The Fedora Cloud WG is poking at the idea of using
>  > KIWI for the cloud image to replace the unmaintained and brittle
>  > ImageFactory, and we could also look at doing container builds with
>  > KIWI to replace the OpenShift Atomic Reactor system. That would
>  > drastically simplify the architecture and make container image builds
>  > considerably more reasonable for the Container SIG and any other
>  > stakeholders.
> 
>  Yeah, thats quite interesting. I would be happy to move to a pipeline
>  thats less fragile here. :)
> 
>  There's also talk about moving things to use ImageBuilder, but I don't
>  think it does containers.
> 
>We can, and should, have RFEs for Image Builder to do containers.  I know
>we need this internally as well.  It may farm that out to buildah in the
>background or something, but that remains to be determined.
>In the interest of commonality across the Fedora/CentOS/RHEL ecosystem, I
>really think using Image Builder as the tool to build images is the best
>approach.

The underlying tool, osbuild, can already build container. They can be made
available as tarball which one can just `podman import` afterward :)


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Non-responsive packager: kasong

[Pierre-Yves Chibon]

Good Morning Everyone,

The packager listed here has been receiving a daily email asking them to
either adjust their bugzilla or their FAS account so the email address in FAS
matches an existing bugzilla account.

Having a bugzilla account is mandatory per:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account


kasong has received daily emails since September 28th.

kasong is main admin of rpms/kdump-anaconda-addon
kasong has a bugzilla override on rpms/kdump-anaconda-addon
kasong is maintainer of rpms/kexec-tools
kasong is main admin of rpms/memstrack
kasong has a bugzilla override on rpms/memstrack
kasong is watching rpms/systemd


Does anyone know how to contact them?


Thanks,

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Using YubiKey for accounts.fedoraproject.org OTP?

[Pierre-Yves Chibon]

On Mon, Sep 27, 2021 at 03:27:43PM +0200, Miro Hrončok wrote:
> Hello,
> 
> I've been trying to add the OPT token from accounts.fedoraproject.org to my
> yubikey. I get a QR code and a otpauth://totp/username?secret=xxx URI.
> 
> I copypasted the xxx secret (56 characters: digits and uppercase letters)
> and tried to add it via YubiKey Manager GUI via Applications/OTP as
> OATH-HOTP (6 digits).
> 
> I get "Failed to configure Long Touch (Slot 2). undefined" error.
> 
> When I tried to use the CLI:
> 
> $ ykman otp hotp -d 6 -c 0 2 xxx
> 
> I get "Error: key lengths >20 bytes not supported".
> 
> Is there a way to use YubiKey for accounts.fedoraproject.org OTP, or is the
> device not compatible?

You may want to check: https://github.com/fedora-infra/noggin/issues/202


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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  Java: The Death of Two SIGs

[Pierre-Yves Chibon]

On Mon, Sep 27, 2021 at 10:57:12AM +0200, Peter Boy wrote:
> 
> 
> > Am 27.09.2021 um 10:47 schrieb Ankur Sinha :
> > 
> > On Sun, Sep 26, 2021 21:20:07 +0200, Fabio Valentini wrote:
> >> Should the @java-maint-sig group be removed from any packages it is
> >> still associated with? Should it be dissolved, and members be removed?
> >> Should the remaining ruins that used to be packages be orphaned?
> >> Retired? Buried? Forgotten?
> >> 
> >> I don't know.
> > 
> > 
> > Unfortunately, I think removing the java-maint-sig is the only thing to
> > do.

As heart-breaking as it is, I agree with Ankur. Letting things as they are is
not correct.
The group itself will not disappear, so if some people wanted to revive it some
time in the future, they could still do, but it would not give the impression
that someone/some team is looking after packages while they are not.

> What do you want to gain from it? What is the goal to be? 

I believe the original email from Fabio answers both of these questions.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Non-responsive packager: michelmno

[Pierre-Yves Chibon]

Good Morning Everyone,

The packager listed here has been receiving a daily email asking them to
either adjust their bugzilla or their FAS account so the email address in FAS
matches an existing bugzilla account.

Having a bugzilla account is mandatory per:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account

- michelmno contacted since July 13th

michelmno is main admin of rpms/libcxl
michelmno is main admin of rpms/libocxl
michelmno is maintainer of rpms/ocaml-camlp5
michelmno is watching rpms/opal-prd


Does anyone know how to contact them?


Thanks,

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: How to get list of retired packages?

[Pierre-Yves Chibon]

On Thu, Sep 16, 2021 at 02:36:58PM +0200, Miroslav Suchý wrote:
> Hi.
> 
> What is the best way to get list of retired packages in F35? I can get list
> of all retired packages by scanning dist-git. But if I want it for one
> release of Fedora? And I do not want to do that manually; I rather want to
> script it.
> 
PDC would be your source of truth for this info. You'll need to look at the
"active" state of the package/branch.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: FAS email for authentication

[Pierre-Yves Chibon]

On Fri, Jul 09, 2021 at 11:13:19AM -0400, Christopher wrote:
> Why does FAS use the email forwarding address when I use it to
> authenticate, rather than the permanent @fedoraproject.org alias for
> the address?
> 
> I should be able to change my forwarding address without changing how
> authentication works. However, it looks like if I change my forwarding
> address, then try to use FAS to log in to Bugzilla, it would tell me
> that there is no account for  and asks if I want
> to register. This currently happens when I try to log in with FAS,
> because I registered my bugzilla account using my
> ctubb...@fedoraproject.org alias instead. Obviously, I don't want to
> create a new account if I change my forwarding address. I can't
> imagine ever wanting to authenticate using my forwarding address,
> rather than my Fedora alias for accessing Fedora systems, because my
> forwarding address is subject to change.
> 
> Every FAS account has a corresponding @fedoraproject.org email alias.

There is the invalid assumption :)
You need to be in one group and have signed the FPCA to have the alias.
You can see have a FAS account and do contribution (for examples to projects
hosted on pagure.io) without either of these requirements.



Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Bochecha unavailable for a little while

[Pierre-Yves Chibon]

Good Morning Everyone,

I am in contact with bochecha who has asked me that I announce his
un-availability for personal reason for a little while.
To this end, he has orphaned the package "buildstream" on Wednesday. There may
be more coming.

Bochecha still wants to come back to Fedora once things have settled down but he
didn't want for anything to wait on him while he is not available.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: rpmautospec: Invitiation to Test

[Pierre-Yves Chibon]

On Tue, Jun 08, 2021 at 02:00:00PM +0200, Nils Philippsen wrote:
> Hey everybody,
> 
> we've recently deployed the changes needed to enable automatic RPM
> release numbers and changelogs to Koji in staging, and now we want you
> to throw things at it!
> 
> Detailed information is below, but the gist is: it looks like this will
> be real sometime soon. This is the time to ensure we folks working on
> it over the past weeks haven't left in any glaring errors.
> 
> We look forward to hearing from you!

I haven't taken the time to test this yet, but I just wanted to send a: thank
you for working on this.

I very much look forward seeing it :)


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: why some package are retired and others are retired without be orphan ?

[Pierre-Yves Chibon]

On Thu, Apr 22, 2021 at 01:53:47PM +0200, Pierre-Yves Chibon wrote:
> On Thu, Apr 22, 2021 at 11:11:37AM +0100, Sérgio Basto wrote:
> > Hi, 
> > 
> > while https://src.fedoraproject.org/rpms/projectM-jack is retired ,
> > 
> > https://src.fedoraproject.org/rpms/publican-fedora and https://src.fedo
> > raproject.org/rpms/gdesklets have the button orphan , why ? 
> 
> Because they still have a main admin?
> If that main admin was "orphan", you would not see that button.
> 
> And in the case of these two packages:
> - publican-fedora has not been orphaned nor retired
> https://src.fedoraproject.org/rpms/publican-fedora/
> https://pdc.fedoraproject.org/rest_api/v1/component-branches/?global_component=publican-fedora=rpm=rawhide
> 
> - gdesklets has not been orphaned but seems to have been retired
> https://src.fedoraproject.org/rpms/gdesklets/
> https://pdc.fedoraproject.org/rest_api/v1/component-branches/?global_component=gdesklets=rpm=rawhide
> 
> 
> > Or better , when the package is retired by some rules like FTBFS or
> > RetirePython2 , the package should be also orphaned . To allow other
> > packager adopt it (IMO). 
> 
> We have a cron that runs monthly and orphans all packages that have been
> retired. 
> Looking at its last run, it should have processed gdesklets:
> > - Orphaning rpms/gdesklets from sergiomb
> > - Removing access on rpms/gdesklets to sergiomb
> 
> I'll try to debug why it did not.

Found it, gdesklet has been orphaned :)


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: why some package are retired and others are retired without be orphan ?

[Pierre-Yves Chibon]

On Thu, Apr 22, 2021 at 11:11:37AM +0100, Sérgio Basto wrote:
> Hi, 
> 
> while https://src.fedoraproject.org/rpms/projectM-jack is retired ,
> 
> https://src.fedoraproject.org/rpms/publican-fedora and https://src.fedo
> raproject.org/rpms/gdesklets have the button orphan , why ? 

Because they still have a main admin?
If that main admin was "orphan", you would not see that button.

And in the case of these two packages:
- publican-fedora has not been orphaned nor retired
https://src.fedoraproject.org/rpms/publican-fedora/
https://pdc.fedoraproject.org/rest_api/v1/component-branches/?global_component=publican-fedora=rpm=rawhide

- gdesklets has not been orphaned but seems to have been retired
https://src.fedoraproject.org/rpms/gdesklets/
https://pdc.fedoraproject.org/rest_api/v1/component-branches/?global_component=gdesklets=rpm=rawhide


> Or better , when the package is retired by some rules like FTBFS or
> RetirePython2 , the package should be also orphaned . To allow other
> packager adopt it (IMO). 

We have a cron that runs monthly and orphans all packages that have been
retired. 
Looking at its last run, it should have processed gdesklets:
> - Orphaning rpms/gdesklets from sergiomb
> - Removing access on rpms/gdesklets to sergiomb

I'll try to debug why it did not.


Thanks,
Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Inactive packagers to be removed from their packages

[Pierre-Yves Chibon]

On Fri, Apr 16, 2021 at 03:25:01PM +0200, Pierre-Yves Chibon wrote:
> Good Morning Everyone,
> 
> When we rolled out the new AAA solution a few weeks ago, some accounts have 
> not
> been migrated:
> - Accounts that have been set inactive by their owner
> - Accounts that are disabled
> - Accounts marked as spam
> 
> This resulted in some packager accounts not being migrated.
> As a consequence, since then, the script that syncs the default-assignee and 
> CC
> list for each component from dist-git to bugzilla has been notifying us about 
> a
> list of packagers in dist-git that could not be synced to bugzilla due to a 
> lack
> of bugzilla account (or rather, in this case, the lack of Fedora account). 
> Since
> these accounts do not exist in the new FAS, I will be removing them from their
> packages on dist-git.
> 
> Here is the list of account impacted:
> - amukunda
> - brolley
> - dp67
> - ianweller
> - jensm
> - jima
> - jjmcd
> - juanmabc
> - kmatsui
> - kurtseifried
> - marcusk
> - rnorwood
> - sindrepb
> - splinux
> - vvitek
> 
> I am planning on removing these users on April 20th. If anyone is opposed to
> this, please let me know.

The only feedback I've had about this email were positive (as in, it should be
done). So I'm going to proceed.


Thanks,
Pierre


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

Re: Non-responsive maintainer: nando pavlix

[Pierre-Yves Chibon]

On Mon, Apr 19, 2021 at 11:51:35AM +0200, Miro Hrončok wrote:
> On 19. 04. 21 10:52, Pierre-Yves Chibon wrote:
> > On Fri, Apr 16, 2021 at 03:12:34PM +0200, Pierre-Yves Chibon wrote:
> > > Good Morning Everyone,
> > > 
> > > The packagers listed here have been receiving a daily email asking them to
> > > either adjust their bugzilla or their FAS account so the email address in 
> > > FAS
> > > matches an existing bugzilla account.
> > > 
> > > Having a bugzilla account is mandatory per:
> > > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account
> > > 
> > > - nando contacted since March 26th
> > > - pavlix contacted since March 18th
> > 
> > Thanks to zoglesby and liangwen12year for fixing their accounts.
> > 
> > Does anyone know how to contact nando and pavlix?
> 
> I know how to contact pavlix.

That seems to have worked, thanks!

The only person left is nando.


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

Re: Disabling BZ `fedora_requires_release_note` flag

[Pierre-Yves Chibon]

On Mon, Apr 19, 2021 at 09:11:19AM -0400, Ben Cotton wrote:
> On Sun, Apr 18, 2021 at 4:13 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > What about the unused "qa contact field"? Kevin suggested dropping
> > qa-extras [1], but it never went anywhere, afaics?
> >
> Good idea. I have a few other BZ cleanup things I want to look at
> post-release. I'll add this to the list.

This one may have been done already actually, worth double checking though.


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

Re: Non-responsive maintainer: nando pavlix

[Pierre-Yves Chibon]

On Fri, Apr 16, 2021 at 03:12:34PM +0200, Pierre-Yves Chibon wrote:
> Good Morning Everyone,
> 
> The packagers listed here have been receiving a daily email asking them to
> either adjust their bugzilla or their FAS account so the email address in FAS
> matches an existing bugzilla account.
> 
> Having a bugzilla account is mandatory per:
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account
> 
> - nando contacted since March 26th
> - pavlix contacted since March 18th

Thanks to zoglesby and liangwen12year for fixing their accounts.

Does anyone know how to contact nando and pavlix?


Pierre
 
> nando is maintainer of rpms/clthreads
> nando is maintainer of rpms/hydrogen
> nando is maintainer of rpms/jamin
> nando is watching rpms/jconv
> nando is maintainer of rpms/jconvolver
> nando is maintainer of rpms/ladspa-amb-plugins
> nando is maintainer of rpms/ladspa-blop-plugins
> nando is maintainer of rpms/ladspa-caps-plugins
> nando is maintainer of rpms/ladspa-cmt-plugins
> nando is maintainer of rpms/ladspa-fil-plugins
> nando is maintainer of rpms/ladspa-mcp-plugins
> nando is maintainer of rpms/ladspa-rev-plugins
> nando is maintainer of rpms/ladspa-tap-plugins
> nando is maintainer of rpms/ladspa-vco-plugins
> nando is maintainer of rpms/muse
> nando is maintainer of rpms/qjackctl
> nando is maintainer of rpms/qsynth
> nando is watching rpms/rtaudio
> nando is main admin of rpms/sooperlooper
> nando has a bugzilla override on rpms/sooperlooper
> nando is maintainer of rpms/swami
> nando is maintainer of rpms/zita-convolver
> 
> pavlix is watching rpms/NetworkManager-iodine
> pavlix is watching rpms/NetworkManager-l2tp
> pavlix is watching rpms/NetworkManager-openconnect
> pavlix is watching rpms/NetworkManager-openvpn
> pavlix is watching rpms/NetworkManager-pptp
> pavlix is maintainer of rpms/NetworkManager-ssh
> pavlix is maintainer of rpms/NetworkManager-strongswan
> pavlix is watching rpms/NetworkManager-vpnc
> pavlix is watching rpms/bind10
> pavlix is maintainer of rpms/dhcpcd
> pavlix is maintainer of rpms/dnsmasq
> pavlix is maintainer of rpms/dnssec-trigger
> pavlix is maintainer of rpms/getdns
> pavlix is maintainer of rpms/hostname
> pavlix is maintainer of rpms/iproute
> pavlix is maintainer of rpms/libecap
> pavlix is maintainer of rpms/python-ptrace
> pavlix is maintainer of rpms/python-pyroute2
> pavlix is maintainer of rpms/radvd
> pavlix is maintainer of rpms/rdist
> pavlix is maintainer of rpms/rsync
> pavlix is maintainer of rpms/squid
> pavlix is maintainer of rpms/strongswan
> pavlix is maintainer of rpms/unbound
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Non-responsive maintainer: liangwen12year nando pavlix zoglesby

[Pierre-Yves Chibon]

On Fri, Apr 16, 2021 at 01:41:41PM -, Zach Oglesby wrote:
> > On Fri, Apr 16, 2021 at 9:19 AM Pierre-Yves Chibon 
> >  > Huh. That still exists? What a throwback!
> > 
> > I sent a tweet in zoglesby's direction. He posted about a week ago, so
> > hopefully he'll see it.
> Fixed

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

Inactive packagers to be removed from their packages

[Pierre-Yves Chibon]

Good Morning Everyone,

When we rolled out the new AAA solution a few weeks ago, some accounts have not
been migrated:
- Accounts that have been set inactive by their owner
- Accounts that are disabled
- Accounts marked as spam

This resulted in some packager accounts not being migrated.
As a consequence, since then, the script that syncs the default-assignee and CC
list for each component from dist-git to bugzilla has been notifying us about a
list of packagers in dist-git that could not be synced to bugzilla due to a lack
of bugzilla account (or rather, in this case, the lack of Fedora account). Since
these accounts do not exist in the new FAS, I will be removing them from their
packages on dist-git.

Here is the list of account impacted:
- amukunda
- brolley
- dp67
- ianweller
- jensm
- jima
- jjmcd
- juanmabc
- kmatsui
- kurtseifried
- marcusk
- rnorwood
- sindrepb
- splinux
- vvitek

I am planning on removing these users on April 20th. If anyone is opposed to
this, please let me know.


At the bottom of this email is the list of component affected for each of these
users.

Thanks,
Pierre


---
amukunda is maintainer of rpms/java-atk-wrapper

brolley is maintainer of rpms/si-units
brolley is watching rpms/systemtap
brolley is maintainer of rpms/uom-lib
brolley is maintainer of rpms/uom-parent
brolley is maintainer of rpms/uom-systems

dp67 is watching rpms/HamFax
dp67 is watching rpms/ax25-apps
dp67 is watching rpms/cwirc
dp67 is maintainer of rpms/demorse
dp67 is watching rpms/dxcc
dp67 is watching rpms/gmfsk
dp67 is watching rpms/gpsk31
dp67 is maintainer of rpms/gpsman
dp67 is maintainer of rpms/gridloc
dp67 is maintainer of rpms/linpsk
dp67 is watching rpms/lpsk31
dp67 is watching rpms/xgridloc
dp67 is maintainer of rpms/xpsk31

ianweller is watching rpms/abattis-cantarell-fonts
ianweller is maintainer of rpms/datagrepper
ianweller is watching rpms/ezstream
ianweller is watching rpms/fedora-business-cards
ianweller is watching rpms/gnome-gmail-notifier
ianweller is watching rpms/irclog2html
ianweller is watching rpms/lordsawar
ianweller is watching rpms/mediawiki-CategoryTree
ianweller is watching rpms/mediawiki-HTTP302Found
ianweller is maintainer of rpms/mediawiki-ParserFunctions
ianweller has a bugzilla override on rpms/mediawiki-ParserFunctions
ianweller is main admin of rpms/mediawiki116-Cite
ianweller has a bugzilla override on rpms/mediawiki116-Cite
ianweller is main admin of rpms/mediawiki116-ParserFunctions
ianweller has a bugzilla override on rpms/mediawiki116-ParserFunctions
ianweller is watching rpms/odfpy
ianweller is watching rpms/openarena
ianweller is maintainer of rpms/python-backports-lzma
ianweller is maintainer of rpms/python-backports-ssl_match_hostname
ianweller is maintainer of rpms/python-fedmsg-meta-debian
ianweller is maintainer of rpms/python-fedmsg-meta-fedora-infrastructure
ianweller is watching rpms/python-flask
ianweller is watching rpms/python-flickrapi
ianweller is watching rpms/python-simplemediawiki
ianweller is main admin of rpms/python-sqlite3dbm
ianweller has a bugzilla override on rpms/python-sqlite3dbm
ianweller is watching rpms/python-transitfeed
ianweller is watching rpms/python-werkzeug
ianweller is watching rpms/rsstool
ianweller is main admin of rpms/supybot-fedora
ianweller is watching rpms/techtalk-pse
ianweller is watching rpms/wordpress-plugin-add-to-any
ianweller is watching rpms/wordpress-plugin-add-to-any-subscribe

jensm is watching rpms/callgit
jensm is watching rpms/perl-Ham-Reference-QRZ
jensm is maintainer of rpms/pisg

jima is maintainer of rpms/alpine
jima is watching rpms/alsa-oss
jima is watching rpms/aoetools
jima is watching rpms/banner
jima is watching rpms/bwm-ng
jima is maintainer of rpms/clusterssh
jima is watching rpms/conserver
jima is watching rpms/dnsmasq
jima is watching rpms/graphviz
jima is watching rpms/libdnet
jima is watching rpms/libstatgrab
jima is watching rpms/miau
jima is watching rpms/ngrep
jima is maintainer of rpms/perl-Device-SerialPort
jima is maintainer of rpms/perl-X11-Protocol
jima is watching rpms/prtconf
jima is watching rpms/putty
jima is watching rpms/rblcheck
jima is watching rpms/scanssh
jima is watching rpms/silo
jima is watching rpms/vblade
jima is watching rpms/videodog
jima is watching rpms/xorg-x11-drv-sunbw2
jima is watching rpms/xorg-x11-drv-suncg14
jima is watching rpms/xorg-x11-drv-suncg3
jima is watching rpms/xorg-x11-drv-suncg6
jima is watching rpms/xorg-x11-drv-sunffb
jima is watching rpms/xorg-x11-drv-sunleo
jima is watching rpms/xorg-x11-drv-suntcx

jjmcd is main admin of rpms/R-qcc
jjmcd has a bugzilla override on rpms/R-qcc
jjmcd is main admin of rpms/rcrpanel
jjmcd has a bugzilla override on rpms/rcrpanel

juanmabc is main admin of rpms/mkproject
juanmabc has a bugzilla override on rpms/mkproject
juanmabc is main admin of rpms/rf
juanmabc has a bugzilla override on rpms/rf
juanmabc is main admin of rpms/tw
juanmabc has a bugzilla override on rpms/tw

kmatsui is main 

Inactive packagers to be removed from their packages

[Pierre-Yves Chibon]

Good Morning Everyone,

When we rolled out the new AAA solution a few weeks ago, some accounts have not
been migrated:
- Accounts that have been set inactive by their owner
- Accounts that are disabled
- Accounts marked as spam

This resulted in some packager accounts not being migrated.
As a consequence, since then, the script that syncs the default-assignee and CC
list for each component from dist-git to bugzilla has been notifying us about a
list of packagers in dist-git that could not be synced to bugzilla due to a lack
of bugzilla account (or rather, in this case, the lack of Fedora account). Since
these accounts do not exist in the new FAS, I will be removing them from their
packages on dist-git.

Here is the list of account impacted:
- amukunda
- brolley
- dp67
- ianweller
- jensm
- jima
- jjmcd
- juanmabc
- kmatsui
- kurtseifried
- marcusk
- rnorwood
- sindrepb
- splinux
- vvitek

I am planning on removing these users on April 20th. If anyone is opposed to
this, please let me know.


At the bottom of this email is the list of component affected for each of these
users.

Thanks,
Pierre


---
amukunda is maintainer of rpms/java-atk-wrapper

brolley is maintainer of rpms/si-units
brolley is watching rpms/systemtap
brolley is maintainer of rpms/uom-lib
brolley is maintainer of rpms/uom-parent
brolley is maintainer of rpms/uom-systems

dp67 is watching rpms/HamFax
dp67 is watching rpms/ax25-apps
dp67 is watching rpms/cwirc
dp67 is maintainer of rpms/demorse
dp67 is watching rpms/dxcc
dp67 is watching rpms/gmfsk
dp67 is watching rpms/gpsk31
dp67 is maintainer of rpms/gpsman
dp67 is maintainer of rpms/gridloc
dp67 is maintainer of rpms/linpsk
dp67 is watching rpms/lpsk31
dp67 is watching rpms/xgridloc
dp67 is maintainer of rpms/xpsk31

ianweller is watching rpms/abattis-cantarell-fonts
ianweller is maintainer of rpms/datagrepper
ianweller is watching rpms/ezstream
ianweller is watching rpms/fedora-business-cards
ianweller is watching rpms/gnome-gmail-notifier
ianweller is watching rpms/irclog2html
ianweller is watching rpms/lordsawar
ianweller is watching rpms/mediawiki-CategoryTree
ianweller is watching rpms/mediawiki-HTTP302Found
ianweller is maintainer of rpms/mediawiki-ParserFunctions
ianweller has a bugzilla override on rpms/mediawiki-ParserFunctions
ianweller is main admin of rpms/mediawiki116-Cite
ianweller has a bugzilla override on rpms/mediawiki116-Cite
ianweller is main admin of rpms/mediawiki116-ParserFunctions
ianweller has a bugzilla override on rpms/mediawiki116-ParserFunctions
ianweller is watching rpms/odfpy
ianweller is watching rpms/openarena
ianweller is maintainer of rpms/python-backports-lzma
ianweller is maintainer of rpms/python-backports-ssl_match_hostname
ianweller is maintainer of rpms/python-fedmsg-meta-debian
ianweller is maintainer of rpms/python-fedmsg-meta-fedora-infrastructure
ianweller is watching rpms/python-flask
ianweller is watching rpms/python-flickrapi
ianweller is watching rpms/python-simplemediawiki
ianweller is main admin of rpms/python-sqlite3dbm
ianweller has a bugzilla override on rpms/python-sqlite3dbm
ianweller is watching rpms/python-transitfeed
ianweller is watching rpms/python-werkzeug
ianweller is watching rpms/rsstool
ianweller is main admin of rpms/supybot-fedora
ianweller is watching rpms/techtalk-pse
ianweller is watching rpms/wordpress-plugin-add-to-any
ianweller is watching rpms/wordpress-plugin-add-to-any-subscribe

jensm is watching rpms/callgit
jensm is watching rpms/perl-Ham-Reference-QRZ
jensm is maintainer of rpms/pisg

jima is maintainer of rpms/alpine
jima is watching rpms/alsa-oss
jima is watching rpms/aoetools
jima is watching rpms/banner
jima is watching rpms/bwm-ng
jima is maintainer of rpms/clusterssh
jima is watching rpms/conserver
jima is watching rpms/dnsmasq
jima is watching rpms/graphviz
jima is watching rpms/libdnet
jima is watching rpms/libstatgrab
jima is watching rpms/miau
jima is watching rpms/ngrep
jima is maintainer of rpms/perl-Device-SerialPort
jima is maintainer of rpms/perl-X11-Protocol
jima is watching rpms/prtconf
jima is watching rpms/putty
jima is watching rpms/rblcheck
jima is watching rpms/scanssh
jima is watching rpms/silo
jima is watching rpms/vblade
jima is watching rpms/videodog
jima is watching rpms/xorg-x11-drv-sunbw2
jima is watching rpms/xorg-x11-drv-suncg14
jima is watching rpms/xorg-x11-drv-suncg3
jima is watching rpms/xorg-x11-drv-suncg6
jima is watching rpms/xorg-x11-drv-sunffb
jima is watching rpms/xorg-x11-drv-sunleo
jima is watching rpms/xorg-x11-drv-suntcx

jjmcd is main admin of rpms/R-qcc
jjmcd has a bugzilla override on rpms/R-qcc
jjmcd is main admin of rpms/rcrpanel
jjmcd has a bugzilla override on rpms/rcrpanel

juanmabc is main admin of rpms/mkproject
juanmabc has a bugzilla override on rpms/mkproject
juanmabc is main admin of rpms/rf
juanmabc has a bugzilla override on rpms/rf
juanmabc is main admin of rpms/tw
juanmabc has a bugzilla override on rpms/tw

kmatsui is main 

Non-responsive maintainer: liangwen12year nando pavlix zoglesby

[Pierre-Yves Chibon]

Good Morning Everyone,

The packagers listed here have been receiving a daily email asking them to
either adjust their bugzilla or their FAS account so the email address in FAS
matches an existing bugzilla account.

Having a bugzilla account is mandatory per:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account

- liangwen12year contacted since April 6th
- nando contacted since March 26th
- pavlix contacted since March 18th
- zoglesby contacted since April 6th


liangwen12year is maintainer of rpms/nmstate

nando is maintainer of rpms/clthreads
nando is maintainer of rpms/hydrogen
nando is maintainer of rpms/jamin
nando is watching rpms/jconv
nando is maintainer of rpms/jconvolver
nando is maintainer of rpms/ladspa-amb-plugins
nando is maintainer of rpms/ladspa-blop-plugins
nando is maintainer of rpms/ladspa-caps-plugins
nando is maintainer of rpms/ladspa-cmt-plugins
nando is maintainer of rpms/ladspa-fil-plugins
nando is maintainer of rpms/ladspa-mcp-plugins
nando is maintainer of rpms/ladspa-rev-plugins
nando is maintainer of rpms/ladspa-tap-plugins
nando is maintainer of rpms/ladspa-vco-plugins
nando is maintainer of rpms/muse
nando is maintainer of rpms/qjackctl
nando is maintainer of rpms/qsynth
nando is watching rpms/rtaudio
nando is main admin of rpms/sooperlooper
nando has a bugzilla override on rpms/sooperlooper
nando is maintainer of rpms/swami
nando is maintainer of rpms/zita-convolver

pavlix is watching rpms/NetworkManager-iodine
pavlix is watching rpms/NetworkManager-l2tp
pavlix is watching rpms/NetworkManager-openconnect
pavlix is watching rpms/NetworkManager-openvpn
pavlix is watching rpms/NetworkManager-pptp
pavlix is maintainer of rpms/NetworkManager-ssh
pavlix is maintainer of rpms/NetworkManager-strongswan
pavlix is watching rpms/NetworkManager-vpnc
pavlix is watching rpms/bind10
pavlix is maintainer of rpms/dhcpcd
pavlix is maintainer of rpms/dnsmasq
pavlix is maintainer of rpms/dnssec-trigger
pavlix is maintainer of rpms/getdns
pavlix is maintainer of rpms/hostname
pavlix is maintainer of rpms/iproute
pavlix is maintainer of rpms/libecap
pavlix is maintainer of rpms/python-ptrace
pavlix is maintainer of rpms/python-pyroute2
pavlix is maintainer of rpms/radvd
pavlix is maintainer of rpms/rdist
pavlix is maintainer of rpms/rsync
pavlix is maintainer of rpms/squid
pavlix is maintainer of rpms/strongswan
pavlix is maintainer of rpms/unbound

zoglesby is main admin of rpms/ghc-X11-xft
zoglesby has a bugzilla override on rpms/ghc-X11-xft
zoglesby is watching rpms/ghc-utf8-string
zoglesby is maintainer of rpms/publican-fedora


Does anyone know how to contact them?


Thanks,

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Has dist-git changed/broken in the last few hours?

[Pierre-Yves Chibon]

On Wed, Mar 31, 2021 at 01:52:16PM +0100, Richard W.M. Jones wrote:
> 
> $ git pull --rebase
> fatal: '/rpms/libguestfs' does not appear to be a git repository
> fatal: Could not read from remote repository.
> 
> Please make sure you have the correct access rights
> and the repository exists.
> 
> $ git remote get-url origin
> ssh://rjo...@pkgs.fedoraproject.org/rpms/libguestfs


I can reproduce. Something is odd.
Looking into it and updated status.fp.o


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

Re: Non-responsive maintainer: kir

[Pierre-Yves Chibon]

On Tue, Mar 16, 2021 at 06:44:21PM +0200, Alexander Bokovoy wrote:
> On ti, 16 maalis 2021, Pierre-Yves Chibon wrote:
> > Good Morning Everyone,
> > 
> > Since February 24th the packager kir has been receiving a daily email asking
> > them to either adjust their bugzilla or their FAS account so the email 
> > address
> > in FAS matches an existing bugzilla account.
> > 
> > Having a bugzilla account is mandatory per:
> > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account
> > 
> > kir is maintainer of rpms/runc
> > 
> > Does anyone know how to contact kir?
> 
> Yes, I asked Kir to respond.

It seems the situation has been fixed, thanks for your help!


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Non-responsive maintainer: kir

[Pierre-Yves Chibon]

Good Morning Everyone,

Since February 24th the packager kir has been receiving a daily email asking
them to either adjust their bugzilla or their FAS account so the email address
in FAS matches an existing bugzilla account.

Having a bugzilla account is mandatory per:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account

kir is maintainer of rpms/runc

Does anyone know how to contact kir?


Thanks,

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: libravatar ported to Fedora's AWS

[Pierre-Yves Chibon]

On Sun, Mar 14, 2021 at 10:32:23PM +, clime wrote:
> Hello,
> 
> I have just finished port of libravatar.org service to server provided
> by Fedora. Big thanks to the Fedora project for sponsoring libravatar.
> Avatars in pagure.io, src.fp.o, Bodhi should now load much faster.

Awesome, thanks!


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

Re: Bodhi client prompting for a password

[Pierre-Yves Chibon]

On Thu, Mar 04, 2021 at 12:15:53AM +0100, Björn Persson wrote:
> Fabio Valentini wrote:
> > On Wed, Mar 3, 2021 at 9:31 PM Miro Hrončok  wrote:
> > >
> > > On 03. 03. 21 21:08, Florian Weimer wrote:  
> > > > I want to run this command:
> > > >
> > > >bodhi updates trigger-tests FEDORA-2021-279dee1742
> > > >
> > > > But I'm prompted for a username and password.  I have a working Kerberos
> > > > setup for koji/fedpkg, so this is somewhat surprising.  Is this
> > > > expected?  
> > >
> > > Yes, that is how bodhi CLI client works.  
> > 
> > Yes. Sadly, most Fedora projects use different methods for
> > authenticating with your FAS account.
> > 
> > koji uses kerberos, bodhi uses OpenID over HTTP, dist-git uses SSH ...
> 
> It wouldn't be a user interface problem if they'd all fetch the
> passcode from the same keyring. Then the user wouldn't need to know how
> many different protocols are used under the hood.

Well kerberos, FAS, OpenID, OIDC are all using the same password. Only the ssh
key can differ depending on how it was created.


Pierre


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

Re: Fedora Account System and Bugzilla Mismatch email

[Pierre-Yves Chibon]

On Wed, Mar 03, 2021 at 11:27:44AM -, Lukas Zapletal wrote:
> Hey,
> 
> I got an email asking me to change my fedora email to match my BZ account. 
> Problem is, in BZ I have to use my redhat account which allows me to be 
> granted special permissions for RH-related bugs. Fedora wants to do this for 
> the same reason, however I'd like to separate my upstream contribution and 
> all accounts from my work account, therefore I'd like to continue using my 
> private email.
> 
> Is this something that can be solved? Like by adding a special field which is 
> used to link BZ so users can set these individually?

There is an override file at:
https://pagure.io/fedora-infra/ansible/raw/main/f/roles/openshift-apps/toddlers/templates/email_overrides.toml
that can be used to, well override email in FAS with email in bugzilla.

Feel free to open a pull-request to edit that file and add yourself :)


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 35 Change: rpmautospec - removing release and changelog fields from spec files (System-Wide Change proposal)

[Pierre-Yves Chibon]

On Wed, Mar 03, 2021 at 01:07:44AM +0100, Miro Hrončok wrote:
> On 02. 03. 21 22:05, Pierre-Yves Chibon wrote:
> > The devil is in the details: pre-release, snapinfo, minorbump aren't really
> > covered by distance being just an integer bumped.
> 
> I don't see this covered in the current method either. Or was it in the
> meantime? Anyway:

It is planned and part of the work to be done with this proposal:
https://docs.pagure.org/fedora-infra.rpmautospec/autorel.html#using-autorel
 
> - pre-release should go into version (~)
> - snapinfo should go into version (~ or ^)
> 
> The only real problem I see here is minorbump. We could have something like:
> %{autorel -m}. That means, micobump since this was added here. But I guess
> it is ugly.
> 
> > I know we considered the "number of commits since the last version bump" 
> > when we
> > looked into this. I honestly do not remember precisely why we didn't go 
> > with it.
> 
> IIRC it was because you considered building several rebuilds with different
> releases from the same commit a goal (while I'd rather require an empty
> commit that explains the reason for the rebuild).

Indeed, that approach would not allow rebuilding a commit without adding a new
(potentially empty) commit.
One of the idea being that not having to add commits would make it easier to do
auto-rebuild of dependency chains.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 35 Change: rpmautospec - removing release and changelog fields from spec files (System-Wide Change proposal)

[Pierre-Yves Chibon]

On Tue, Mar 02, 2021 at 09:30:41PM +0100, Fabio Valentini wrote:
> On Tue, Feb 16, 2021 at 8:20 PM Pierre-Yves Chibon  
> wrote:
> >
> > On Tue, Feb 16, 2021 at 03:38:35PM +0100, Fabio Valentini wrote:
> > > On Tue, Feb 16, 2021 at 3:01 PM Miro Hrončok  wrote:
> > > >
> > > > On 16. 02. 21 14:48, Fabio Valentini wrote:
> > > > >  if version_at(commit) != last_version:
> > > > >  return 0
> > > >
> > > > Should this be "return 1"?
> > >
> > > No, 0 is correct. If the version does not match, this is the last
> > > commit *before* a version update.
> > > The "max(parents) + 1" then sets the Release to 1 for the commit that
> > > actually changed the version :)
> > >
> > > > To prevent accidental divergence between the git history and the build 
> > > > system.
> > > > That's why this information is only used in the koji plugin, locally 
> > > > (ie: via
> > > > the rpmautospec CLI) it only relies on the git tags.
> > >
> > > So ... you want to *prevent* divergence by *introducing* divergence? I
> > > do not follow ...
> >
> > The build information is used to check if all the builds made in koji 
> > exists as
> > tags. If they don't, then they are added, thus resolving the divergence.
> > If they do, git tags are used, just like they are used locally.
> 
> There's another issue that I see with using both git tags and koji
> build history:
> How do users get those tags into their local repository clones, if
> they are created by koji after successful builds?

The first time it can be done via the rpmautospect CLI command.

> Will we need to "git pull" after every successful koji build so we get
> consistent results between local checkout and infra build?

After that, git pull/fetch is indeed the easiest method.

> Side note: This amended algorithm should always produce incrementing
> release numbers, even across branches:
> 
> def release_num(commit, last_version) -> int:
> if version_at(commit) != last_version:
> return 0
> else:
> distance = max(release_num(parent, last_version) for parent of 
> commit))
> if is_merge_commit(commit):
> return distance
> else:
> return distance + 1
> 
> That should solve both the upgrade path issue and the data source
> problem. No need to look at either git tags or koji build history :)

The devil is in the details: pre-release, snapinfo, minorbump aren't really
covered by distance being just an integer bumped.

I know we considered the "number of commits since the last version bump" when we
looked into this. I honestly do not remember precisely why we didn't go with it.

Maybe Nils or Adam remember it?


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Non-responsive maintainer: sabbaka

[Pierre-Yves Chibon]

Good Morning Everyone,

Since February 7th the packager sabbaka has been receiving a daily email asking
them to either adjust their bugzilla or their FAS account so the email address
in FAS matches an existing bugzilla account.

Having a bugzilla account is mandatory per:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account

sabbaka is maintainer of rpms/tlog

Does anyone know how to contact sabbaka?


Thanks,

Pierre



PS: the users dkaspar, kir and leogallego having been receiving the same email
since February 24th. Their attention to that email would be appreciated.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: git push on master branch rejected.

[Pierre-Yves Chibon]

On Mon, Feb 22, 2021 at 09:28:53AM -0500, Steve Dickson wrote:
> 
> 
> On 2/22/21 2:39 AM, Pierre-Yves Chibon wrote:
> > On Sun, Feb 21, 2021 at 05:21:33PM -0500, Steve Dickson wrote:
> >>
> >> Thanks you for your rapid reply! 
> >>
> >> On 2/21/21 4:57 PM, Michael Young wrote:
> >>> On Sun, 21 Feb 2021, Steve Dickson wrote:
> >>>
> >>>> I apologies if I missed something... If there is a
> >>>> thread that talks about this please point me at it
> >>>> but...
> >>>>
> >>>> when I do a git push on the master branch I get:
> >>> ...
> >>>
> >>> You missed the branch renaming - master has been replaced by rawhide with 
> >>> alias main.
> >> I figured it was something like that... but when I do a git branch -r I 
> >> don't 
> >> see the rawhide branch... So how do I move from master to rawhide?
> >>
> >> From your explanation I figured all I had to is a
> >>  git checkout -b main origin/main
> >>
> >> which worked but when I do a git pull I get
> >>
> >> $ git pull
> >> error: cannot lock ref 'refs/remotes/origin/rawhide': 
> >> 'refs/remotes/origin/rawhide/user/steved/pnfs-rawhide' exists; cannot 
> >> create 'refs/remotes/origin/rawhide'
> >> From ssh://pkgs.fedoraproject.org/rpms/nfs-utils
> >>  ! [new branch]  rawhide-> origin/rawhide  (unable to update local 
> >> ref)
> >>
> >> It appears that a very old refs "origin/rawhide/user/steved/pnfs-rawhide" 
> >> is messing things up... so how do I get ride of that old refs?
> > 
> > I have renamed it on the server side, so if you try again this should work 
> > now
> > :)
> Thank you... but I still unable to create the rawhide branch:
> 
> git pull
> error: cannot lock ref 'refs/remotes/origin/rawhide': 
> 'refs/remotes/origin/rawhide/user/steved/pnfs-rawhide' exists; cannot create 
> 'refs/remotes/origin/rawhide'
> From ssh://pkgs.fedoraproject.org/rpms/nfs-utils
>  ! [new branch]  rawhide-> origin/rawhide  (unable to update local 
> ref)
>  * [new branch]  rawhide_old/user/steved/pnfs-rawhide -> 
> origin/rawhide_old/user/steved/pnfs-rawhide
> 
> Doing the pull again I get:
> 
> git pull
> error: cannot lock ref 'refs/remotes/origin/rawhide': 
> 'refs/remotes/origin/rawhide/user/steved/pnfs-rawhide' exists; cannot create 
> 'refs/remotes/origin/rawhide'
> From ssh://pkgs.fedoraproject.org/rpms/nfs-utils
>  ! [new branch]  rawhide-> origin/rawhide  (unable to update local 
> ref)

Do you have the old rawhide/user/sted/pnfs-rawhide branch in your local clone?
If so, try git fetch -p or just delete the branch (since it was renamed, you
could checkout rawhide_old/user/steved/pnfs-rawhide at any point).

It seems the issue is with your local clone.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: git push on master branch rejected.

[Pierre-Yves Chibon]

On Sun, Feb 21, 2021 at 05:21:33PM -0500, Steve Dickson wrote:
> 
> Thanks you for your rapid reply! 
> 
> On 2/21/21 4:57 PM, Michael Young wrote:
> > On Sun, 21 Feb 2021, Steve Dickson wrote:
> > 
> >> I apologies if I missed something... If there is a
> >> thread that talks about this please point me at it
> >> but...
> >>
> >> when I do a git push on the master branch I get:
> > ...
> > 
> > You missed the branch renaming - master has been replaced by rawhide with 
> > alias main.
> I figured it was something like that... but when I do a git branch -r I don't 
> see the rawhide branch... So how do I move from master to rawhide?
> 
> From your explanation I figured all I had to is a
>  git checkout -b main origin/main
> 
> which worked but when I do a git pull I get
> 
> $ git pull
> error: cannot lock ref 'refs/remotes/origin/rawhide': 
> 'refs/remotes/origin/rawhide/user/steved/pnfs-rawhide' exists; cannot create 
> 'refs/remotes/origin/rawhide'
> From ssh://pkgs.fedoraproject.org/rpms/nfs-utils
>  ! [new branch]  rawhide-> origin/rawhide  (unable to update local 
> ref)
> 
> It appears that a very old refs "origin/rawhide/user/steved/pnfs-rawhide" 
> is messing things up... so how do I get ride of that old refs?

I have renamed it on the server side, so if you try again this should work now
:)


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: restic update and src.fedoraproject.org and Self Introduction

[Pierre-Yves Chibon]

On Wed, Feb 17, 2021 at 07:19:26PM -0500, Kevin Anderson wrote:
> Thank you! I'm unsure of what I was doing wrong initially but I
> appreciate your help in resolving it!

As James pointed out you'll need to use fedpkg if you're not a packager.
The workflow is documented at:
https://docs.fedoraproject.org/en-US/ci/pull-requests/#_you_are_not_a_packager


Pierre


> On Tue, Feb 16, 2021 at 9:17 PM James Cassell
>  wrote:
> >
> >
> >
> > On Tue, Feb 16, 2021, at 8:06 PM, Kevin Anderson wrote:
> > [...]
> > > The issue is that when I attempt to push over HTTPS I get an
> > > authentication failure. I have tried with an API key as well as with
> > > my FAS password using my FAS username (kanderson) for both. Is it
> > > expected that I can't push, even to a fork, if I am not a part of a
> > > packagers group?
> >
> > re-clone the repo using `fedpkg clone --anonymous`, then `git remote add 
> > fork `, then you can follow the prompts when you attempt to 
> > push to your fork. (it'll get you to open a browser and sign-in there)
> >
> > V/r,
> > James Cassell
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/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

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

[Pierre - Yves Chibon]

On Wed, Feb 17, 2021 at 08:00:49PM +0100, Miro Hrončok wrote:
> On 17. 02. 21 19:46, Eugene Syromiatnikov wrote:
> > On Thu, Dec 03, 2020 at 10:02:34AM -0500, Ben Cotton wrote:
> > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> > > 
> > > == Summary ==
> > > 
> > > This Change will move Fedora git repositories to use "main" as the
> > > default git branch instead of "master". Specific repositories will be
> > > manually moved and default git branch for new projects will be set to
> > > use "main".
> > 
> > The way this change has been performad made at least rpms/microcode_ctl
> > repository unusable[1][2] by koji.
> > 
> > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=62174686
> > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=62174675
> 
> The same happens locally:
> 
> $ fedpkg clone microcode_ctl
> Cloning into 'microcode_ctl'...
> remote: Enumerating objects: 994, done.
> remote: Counting objects: 100% (994/994), done.
> remote: Compressing objects: 100% (773/773), done.
> remote: Total 994 (delta 477), reused 411 (delta 208), pack-reused 0
> Receiving objects: 100% (994/994), 3.30 MiB | 3.01 MiB/s, done.
> Resolving deltas: 100% (477/477), done.
> fatal: cannot process 'refs/remotes/origin/rawhide' and
> 'refs/remotes/origin/rawhide/user/kyle/amd-ucode-2011-01-11' at the same
> time
> Could not execute clone: Failed to execute command.

Could you try again?

refs/heads/rawhide/user/kyle/amd-ucode-2011-01-11 has been renamed to
refs/heads/rawhide_old/user/kyle/amd-ucode-2011-01-11
that should remove the conflict.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 35 Change: rpmautospec - removing release and changelog fields from spec files (System-Wide Change proposal)

[Pierre-Yves Chibon]

On Tue, Feb 16, 2021 at 03:38:35PM +0100, Fabio Valentini wrote:
> On Tue, Feb 16, 2021 at 3:01 PM Miro Hrončok  wrote:
> >
> > On 16. 02. 21 14:48, Fabio Valentini wrote:
> > >  if version_at(commit) != last_version:
> > >  return 0
> >
> > Should this be "return 1"?
> 
> No, 0 is correct. If the version does not match, this is the last
> commit *before* a version update.
> The "max(parents) + 1" then sets the Release to 1 for the commit that
> actually changed the version :)
> 
> > To prevent accidental divergence between the git history and the build 
> > system.
> > That's why this information is only used in the koji plugin, locally (ie: 
> > via
> > the rpmautospec CLI) it only relies on the git tags.
> 
> So ... you want to *prevent* divergence by *introducing* divergence? I
> do not follow ...

The build information is used to check if all the builds made in koji exists as
tags. If they don't, then they are added, thus resolving the divergence.
If they do, git tags are used, just like they are used locally.



Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 35 Change: rpmautospec - removing release and changelog fields from spec files (System-Wide Change proposal)

[Pierre-Yves Chibon]

On Tue, Feb 16, 2021 at 02:48:23PM +0100, Fabio Valentini wrote:
> On Fri, Feb 12, 2021 at 5:20 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/rpmautospec
> >
> > == Summary ==
> > The goal of this change is to deploy in production the
> > [https://docs.pagure.org/fedora-infra.rpmautospec/ rpmautospec]
> > project.
> >
> > With it, the content of the `Release` and `%changelog` fields in spec
> > files can be auto-generated, either locally or in the builder using
> > the information present in the git repo (in the form of git tags).
> >
> >
> > Note: This proposal is about changing the way the `Release` and
> > `%changelog` sections of the '''spec files''' are filled, not about
> > removing them from the SRPM or binary RPM.
> >
> > == Owner ==
> > * Name: [[User:pingou| Pierre-Yves Chibon]]
> > * Email: pingou - at - pingoured.fr
> > * Name: [[User:nphilipp| Nils Philippsen]]
> > * Email: nphilipp - at - redhat.com
> >
> >
> > == Detailed Description ==
> >
> > rpmautospec offers packagers who want to use it the possibility of
> > replacing the content of the `Release` of their spec file by `Release:
> >%autorel` and/or replace the content of the `%changelog` section of
> > their spec file by:
> >   %changelog
> >   %autochangelog
> >
> > Both `%autorel` and `%autochangelog` are RPM macros that will be
> > expanded or replaced when the SRPM is built on the build system by
> > their corresponding values according to rpmautospec.
> >
> > An overview of how rpmautospec works can be found at:
> > https://docs.pagure.org/fedora-infra.rpmautospec/principle.html.
> > We will describe below how each macro works.
> >
> > === The %autorel macro ===
> >
> > To determine the next release information, rpmautospec relies on the
> > build history of the package.
> > This information is extracted from the buildsystem when running as a
> > koji plugin and from git tags when running outside of the buildsystem.
> >
> > Using the build history of the package (ie a list of NEVRs) as well as
> > the information provided by the packager in the spec file, rpmautospec
> > then computes the next best release number for the package.
> >
> > Once defined, it prepends a suitably defined %autorel macro to the top
> > of the spec file, freezing the computed value of the release number
> > and thus allowing reproducible builds of the SRPM.
> >
> > The [https://docs.pagure.org/fedora-infra.rpmautospec/autorel.html
> > documentation of the autorel macro] describes how packagers can use it
> > to provide extra information.
> 
> I wonder why you're not relying solely on git history for both local
> builds and in koji?

To prevent accidental divergence between the git history and the build system.
That's why this information is only used in the koji plugin, locally (ie: via
the rpmautospec CLI) it only relies on the git tags.

Using the number of commits can give weird results with merge commits and even
though the upgrade path is not really an issue anymore, we preferred to try
preserving it. So rpmautospec should minimize the risk of broken upgrade path.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 35 Change: rpmautospec - removing release and changelog fields from spec files (System-Wide Change proposal)

[Pierre-Yves Chibon]

On Fri, Feb 12, 2021 at 06:08:31PM +0100, Miro Hrončok wrote:
> On 12. 02. 21 17:20, Ben Cotton wrote:
> > ** Adjust the packaging so rpmautospec does not live in a specific,
> > versionized python environment (and thus could be use to bootstrap
> > python)
> 
> Thank you!
> 
> Don't hesitate to let me know once there is testable proof of concept for
> this, so I can try to break it again :D

Sure thing, with pleasure! :D


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Pierre-Yves Chibon]

On Wed, Feb 10, 2021 at 09:59:24AM -0500, Matthew Miller wrote:
> On Wed, Feb 10, 2021 at 03:50:06PM +0100, Fabio Valentini wrote:
> > This is something we explicitly did not want on the git level, which
> > is why there is a main → rawhide link, but no master → rawhide link.
> > But it could possibly be done on the HTTP level in pagure, with a redirect?
> 
> Yeah, if not too much work this would be really beneficial. Lots of existing
> links out there.

We've added redirects to links pointing to files in the 'master' branch to the
new default branch.
For example:
https://src.fedoraproject.org/rpms/klickety/blob/master/f/klickety.spec#_68 
will redirect you to
https://src.fedoraproject.org/rpms/klickety//blob/rawhide/f/klickety.spec#_68

This should help with some of the links.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: More distgit attached to Fedora Zuul CI

[Pierre - Yves Chibon]

On Tue, Feb 09, 2021 at 03:35:11PM +0100, Miro Hrončok wrote:
> On 09. 02. 21 15:27, Tom Stellard wrote:
> > Has there been any more discussion about disabling simple-koji-ci on
> > packages with Zuul enabled?
> 
> It's generally disabled AFAIK. Or broken. Same outcome.

AFAIK it's still running. Happy to decommission it though.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Pierre-Yves Chibon]

On Fri, Feb 05, 2021 at 03:35:27PM +0100, Vít Ondruch wrote:
> 
> Dne 05. 02. 21 v 12:39 Pierre-Yves Chibon napsal(a):
> > On Fri, Feb 05, 2021 at 12:11:45PM +0100, Florian Weimer wrote:
> > > * Kevin Fenzi:
> > > 
> > > > Once the change is completed you will want to checkout rawhide/main
> > > > instead of master and update/recreate any existing forks you have.
> > > > 
> > > > See
> > > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> > > > for more information.
> > > Would it be possible to add the sequence of commands to the proposal to
> > > convert an existing clone with unpushed changes?
> > > 
> > > I think it is something along the lines of (for src.fedoraproject.org):
> > > 
> > > git checkout master
> > > git branch --move rawhide
> > > git branch --set-upstream-to=origin/rawhide
> > > 
> > > I'm not entire sure if “rawhide“ is the correct branch to use, and if
> > > the sequence of commands is the right one.
> > All of the above is correct.
> > 
> > I'll add it to the wiki page, thanks for the suggestion!
> 
> 
> If there was even chance to include how to change the whole bunch of such
> repositories at once, that'd be appreciate by many I guess.

Something like:
# if you keep all your git clone in the same folder, run this at the top of that
# folder:
for i in `ls -1`; do pushd $i && echo $i && git fetch && git checkout master && 
\
git branch --move rawhide && git branch -u origin/rawhide && popd ; done

The issue being that if one of the step fails in one of your clones, the entire
loop will stop and won't run another time :/


Pierre


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

Re: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Pierre-Yves Chibon]

On Fri, Feb 05, 2021 at 12:11:45PM +0100, Florian Weimer wrote:
> * Kevin Fenzi:
> 
> > Once the change is completed you will want to checkout rawhide/main
> > instead of master and update/recreate any existing forks you have.
> >
> > See
> > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> > for more information.
> 
> Would it be possible to add the sequence of commands to the proposal to
> convert an existing clone with unpushed changes?
> 
> I think it is something along the lines of (for src.fedoraproject.org):
> 
> git checkout master
> git branch --move rawhide
> git branch --set-upstream-to=origin/rawhide
> 
> I'm not entire sure if “rawhide“ is the correct branch to use, and if
> the sequence of commands is the right one.

All of the above is correct.

I'll add it to the wiki page, thanks for the suggestion!


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Proposal: gate stable release critical path updates on openQA test results

[Pierre-Yves Chibon]

On Fri, Jan 08, 2021 at 05:24:11PM -0500, Matthew Miller wrote:
> On Fri, Jan 08, 2021 at 09:34:29PM +0100, Kevin Kofler via devel wrote:
> > > So if anything, I think this change is in line with your views here.
> > 
> > Well, if (and as long as) the gating only blocks the autopush and does not 
> > prevent a manual push (as yet another requirement), I withdraw my objection.
> 
> I think we should get to the point where it blocks manual pushes (without
> the failure being waved). If the test is broken, fix the test.

This is basically what this thread is asking. If we make a test mandatory, no
updates will be pushed when this test fails unless the failure is waived.

So it seems we are all in agreement!


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: HOWTO: Change default branch on pagure.io projects

[Pierre-Yves Chibon]

On Wed, Jan 06, 2021 at 07:16:44AM -, Wolfgang Stoeggl via devel wrote:
> > git push origin :master
> > (This deletes the old ‘master’ branch)
> 
> git push origin :master
> remote: Branch deletion is not allowed
> remote: Denied push for ref 'refs/heads/master' for user '**'
> remote: All changes have been rejected

Which project/host are you trying to push to?
This is allowed on pagure.io but if you're trying on src.fp.o it will be blocked
(and this is expected). We will be doing src.fp.o directly server side, we'll
simply be renaming the master ref to rawhide (to by-pass the git hook which does
what you're seeing here) and create the symlink main -> rawhide.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Planned Outage - taiga - 2021-01-05 07:00 UTC

[Pierre-Yves Chibon]

On Thu, Dec 31, 2020 at 05:33:08PM +0100, Pierre-Yves Chibon wrote:
> There will be an outage starting at 2021-01-05 07:00 UTC
> which will last approximately 3 hours.
> 
> To convert UTC to your local time, take a look at
> http://fedoraproject.org/wiki/Infrastructure/UTCHowto
> or run:
> date -d '2021-01-05 07:00UTC'
> 
> 
> Reason for outage:
> Upgrade to a more recent/patched taiga
> 
> 
> Affected Services:
> Only taiga (ie: teams.fedoraproject.org)

This outage is now over.

Here is the gist of the changes:
"""
We have successfully deployed the patch release on your Taiga instance.

You have the full changelog at our repositories, but the most notable changes 
are:

- We fixed attachment refresh on comments and the wiki
- We now render custom fields and block reason as Markdown (more powerful 
parsing, allows for hyperlinks, for example)
"""


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[Pierre-Yves Chibon]

On Thu, Dec 17, 2020 at 09:14:40PM +0100, Fabio Valentini wrote:
> On Thu, Dec 17, 2020 at 8:06 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing
> >
> >
> > == Summary ==
> > This change should enable an opt-in spec file preprocessor in Fedora
> > infrastructure for the benefit of packagers. The preprocessor allows
> > some very neat tricks that were impossible before, for example
> > generate changelog and release automatically from git metadata or pack
> > the entire dist-git repository into an rpm-source tarball (effectively
> > allowing unpacked repos to live in DistGit).
> 
> As far as I can tell, this is the third implementation of generated
> changelogs ... did the autorelease / autochangelog work that was even
> already deployed in staging not go anywhere?

If you're thinking about rpmautospec, I have in mind to submit it as a change
proposal in the coming month. Fall has been quite busy after the data center
move and I also did not want to have everyone check it and FESCo spend time on
it in a timeframe where we couldn't put up with the work afterward.
So my idea is to submit it in Q1 (Jan-March) to start on it (if approved) in Q2
(May-June).


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Stale proven packagers

[Pierre-Yves Chibon]

On Tue, Dec 22, 2020 at 01:39:26PM -0800, Adam Williamson wrote:
> On Tue, 2020-12-22 at 13:23 -0800, Kevin Fenzi wrote:
> > 
> > > Perhaps we need a process for cleaning up membership of this extremely
> > > powerful group? If the FAS password of *any one* of those user accounts
> > > were somehow compromised (or if just one of them decided they had a
> > > grudge against Fedora now and were going to have some fun), the results
> > > could be...unfortunate.
> > 
> > Oh look, flashback 13 years: 
> > 
> > https://fedoraproject.org/wiki/User:JesseKeating/AutomatedMIAProposal?rd=JesseKeating/AutomatedMIAProposal
> > 
> > Anyhow, I was in favor of something then, but it got shouted down, and I
> > am still in favor now of some kind of checkin process. I think it should
> > be light weight tho... always being bothered is bad. On the other hand
> > it's hard to know how to notify people. If you send email once a week
> > for 4 weeks and get no answer does that mean they are missing? Or that
> > your email is going to the spam folder? Or that they are on a long
> > vacation not checking email? It's hard to balance. 
> 
> So that proposal was just for all packagers. I think it should at least
> be reasonable to set a relatively high bar for being a provenpackager.
> Proven packagers really should be people who are deeply involved in
> Fedora work on a daily basis, I think, and so should be able to respond
> to a regular check-in process like this or the one bcotton proposed.
> And the result would only be that they'd lose provenpackager
> privileges, which could quite easily be restored if it turned out
> they'd just gone on a yak farming retreat for a bit or something.

The fedora-active-user script also checks the last date/time the user logged
into FAS (I should check how that'll work with noggin).
This could be re-used here and a simple mechanism to opt-out of the procedure
once initiated.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Stale proven packagers

[Pierre-Yves Chibon]

On Tue, Dec 22, 2020 at 12:39:56PM -0800, Adam Williamson wrote:
> A propos of some discussion of the Solarwinds news, it occurred to me
> to check how many proven packager accounts there are in FAS. There are
> 251, which seems like a lot. Then it occurred to me to check how many
> of them are inactive, so I wrote a little script:
> 
> ===
> 
> #!/usr/bin/python3
> 
> import getpass
> 
> from fedora.client.fas2 import AccountSystem
> from koji import ClientSession
> 
> username = input("FAS user name: ")
> password = getpass.getpass("FAS password: ")
> 
> acc = AccountSystem(username=username, password=password)
> pps = acc.group_members("provenpackager")
> 
> ks = ClientSession("https://koji.fedoraproject.org/kojihub;)
> for pp in pps:
> user = ks.getUser(pp["username"])
> if not user:
> print(f"{pp['username']} NON-EXISTENT IN KOJI")
> continue
> uid = user["id"]
> if ks.listBuilds(userID=uid, createdAfter="2019-01-01 00:00:00"):
> continue
> print(pp["username"])

One thing missing there is the check if the account is still active in FAS. In
the case of Seth you'll see it has been disabled for a long time. So there no
security risk with that account.


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

Planned Outage - taiga - 2021-01-05 07:00 UTC

[Pierre-Yves Chibon]

There will be an outage starting at 2021-01-05 07:00 UTC
which will last approximately 3 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2021-01-05 07:00UTC'


Reason for outage:
Upgrade to a more recent/patched taiga


Affected Services:
Only taiga (ie: teams.fedoraproject.org)


Ticket Link:
https://pagure.io/fedora-infrastructure/issue/9552


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

Planned Outage - taiga - 2021-01-05 07:00 UTC

[Pierre-Yves Chibon]

There will be an outage starting at 2021-01-05 07:00 UTC
which will last approximately 3 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2021-01-05 07:00UTC'


Reason for outage:
Upgrade to a more recent/patched taiga


Affected Services:
Only taiga (ie: teams.fedoraproject.org)


Ticket Link:
https://pagure.io/fedora-infrastructure/issue/9552


Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.
___
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: GitLab AMA Topic Follow Up: Branches

[Pierre-Yves Chibon]

On Sun, Dec 13, 2020 at 04:18:44PM +, Aoife Moloney wrote:
> Hi everyone,
> 
> Its been a few weeks but there are still two topics left to cover from
> the original AMA session. This week's topic is Branches. As always,
> below are some links to the original documents and chat logs from the
> IRC session, and the main body of this mail is the questions and
> answers pulled directly from the Q sheet that specifically relate to
> branches.
> * Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
> * Chat log from session
> https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html
> * AMA Blog post
> https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
> * Here is this email in hackmd if you wish to view it there:
> https://hackmd.io/me-0oLN-Qtmff1qMX2S-DA?view
> 
> ## Topic: Branches
> Force pushing  - Protected Branches
> - Question: Fedora forbids force-push in the main projects but allows
> them in forks. Would this be feasible in GitLab in a way that people
> cannot revert?
> - Answer: This can be done with Protected branches, basically
>  
> (https://docs.gitlab.com/ee/user/project/protected_branches.html#protected-branches)
> 
> Archived branches - Protected Branches
> - Question: Fedora supports the concept of retired git `branch` (ie:
> archived) that no-one can commit. Does GitLab have an equivalent
> concept? (The retired status is not something project admins can
> change)
> - Answer: Yes this is possible with Protected Branches
> https://docs.gitlab.com/ee/user/project/protected_branches.html#protected-branches
> - Question: Extending to above question, the sla's or eol dates are
> coming from a 3rd party service, when a user pushes to git branch, it
> will check the eol in that service and rejects it if it is already
> eol'd. Is this possible in GitLab?
> - Answer: Instead of this we would probably use the Protected
> Branches in GitLab. We could leverage the APIs to mass configure the
> branches on eol dates. That would mean that for each git push we don’t
> need to look at a 3rd party service to know if we can push or not.

This would work for regular releases, but for module branches I'm not sure how
it'll scale.

> - Question: It is not allowed for users to delete the branches, only
> certain people with certain access levels are allowed to perform this
> operation. Is this possible in GitLab?
> - Answer: Yes protected branches can be used here
> https://docs.gitlab.com/ee/user/project/protected_branches.html#protected-branches
> 
> Push permissions
> - Question: In CentOS, members of a group (say: storage-sig) can push
> to any branch starting with c--* (so for example, they
> can push to : c8-storage-sig-v2.0 or c7-storage-sig), but they cannot
> push to any other branches, like: c8, c7 or any of the branches
> starting with c8-kernel-sig and so on. Would this be doable in GitLab?
> (in a way that project owner/maintainer cannot edit?)
> - Answer: A Custom Push Rule and server hook (pre-recieve Git
> hooks behind the scenes) could help with this.
> 
> - Question: Can we set permissions at branch level? Esp can we set
> them with some regex matching?
> - Answer: permissions accept wildcards, but not regexes. Regex can
> be used with custom push rules. See
> https://docs.gitlab.com/ee/push_rules/push_rules.html and
> https://docs.gitlab.com/ee/user/project/protected_branches.html#configuring-protected-branches.
> 
> Hiding branches
> - Question: Is it possible to hide these retired branches from the UI?
> Say, hide branch names with f30 or lower?
> - Answer: This is not possible currently
> 
> - Question: Currently a user is not allowed to rewrite the history. Is
> it possible? It would be nice to allow only certain people to do so.
> Although we might not use this, but its good to have just in case if
> we ever need it.
> - Answer: by default, only the `master` branch is protected
> against force push and deletion. It’s possible to configure other
> branches to be protected and who has permission to override.
> https://docs.gitlab.com/ee/user/project/protected_branches.html#configuring-protected-branches

Master or the default branch?

> Branch level orphaning
> - Question: Orphaning a package or repo? A maintainer (owner) of the
> package can decide to orphan a package, the maintainer should only be
> able to assign the package to the `orphan` user or any of the other
> maintainers of the package only. Is this possible to set this branch
> level as well?
> - Answer: Yes, in the sense that who is allowed to push or merge
> to a specific branch is controllable at the user or group level. This
> can be at the specific branch level or based on a wildcard match based
> on branch name. See configuring protected branches for more details.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe 

Re: koji buildsystem changes

[Pierre-Yves Chibon]

On Sun, Dec 13, 2020 at 08:42:53PM -0700, Jerry James wrote:
> On Sun, Dec 13, 2020 at 3:22 PM Kevin Fenzi  wrote:
> > * Finally releng is looking at establishing a sidetag cleanup policy.
> > A reminder that sidetags should be short lived and only created when
> > needed. koji must generate buildroot repos for every single sidetag.
> > ( You can list all your sidetags with 'fedpkg list-side-tags --mine' )
> 
> On this page:
> 
> https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/
> 
> there is a box marked "Important" that says:
> 
> "If you have created a side-tag and have no use for it (and did not
> create an update for it), please remove it so it does consume
> resources on the build infrastructure. You can simply remove side-tags
> you have created using fedpkg remove-side-tag and you can list your
> side tags using fedpkg list-side-tags --user=."
> 
> The parenthetical remark in the first sentence says to me that if I
> have created an update from a side tag, that I should not remove the
> side tag.  Is that correct?  Indeed, if I run fedpkg list-side-tags, I
> see 5, when in fact every side tag that I have created has been
> merged.  Should I delete all of those?  I created updates for each one
> of them.

Normally side-tags that went through bodhi should be cleaned up by bodhi, if
they have not been you can clean them manually without problem.
The issue this text was trying to prevent was the case where someone builds one
or more packages in their side-tag and delete said side-tag before submitting
the builds as an update, thus effectively untagging the builds from all tags and
making them available to be picked up by koji's garbage collection.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 34 Change: GitRepos-master-to-main (Self-Contained Change)

[Pierre-Yves Chibon]

On Thu, Dec 10, 2020 at 10:29:12AM -0800, Kevin Fenzi wrote:
> On Thu, Dec 10, 2020 at 10:36:36AM +0100, Robert-André Mauchin wrote:
> > On 12/3/20 4:02 PM, Ben Cotton wrote:
> > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> > > 
> > > == Summary ==
> > > 
> > > This Change will move Fedora git repositories to use "main" as the
> > > default git branch instead of "master". Specific repositories will be
> > > manually moved and default git branch for new projects will be set to
> > > use "main".
> > > 
> > > The Fedora Community strives to be open and welcoming. Some language
> > > around our git repositories is dated and could be more inclusive. Many
> > > git repositories currently use "master" as the default branch. This
> > > Change will move many repositories (see below) to use a "main" branch
> > > as default. This small bit of naming adjustment is in-line with
> > > Fedora's vision for free and open source software built by inclusive,
> > > welcoming, and open-minded communities.
> > > 
> > > 
> > 
> > How does it work for the enduser? I have thousand of git repos locally with
> > the master branch, will it rename automatically master to main when I git
> > pull or do I need to run a special command?
> 
> You will need to reclone or run some commands in those existing
> checkouts. 
> 
> If you have a clone that has 'master' branch and we delete that, and you
> 'git pull' you will get: 
> 
> Fetching origin
> Your configuration specifies to merge with the ref 'refs/heads/master'
> from the remote, but no such ref was fetched.
> 
> So you will need to do: 
> 
> git checkout main
> git branch --set-upstream-to=origin/main main

Since the main branch will exist on the remote, you may be able to do:
git fetch
git checkout main

and I think the git branch --set-upstream-to is no longer needed then

> then git pull. 
> 
> I don't think there's anything we can do on the server side to make that
> easier. Pingou any ideas?

Not at the moment.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 34 Change: GitRepos-master-to-main (Self-Contained Change)

[Pierre-Yves Chibon]

On Thu, Dec 03, 2020 at 04:56:09PM +0100, Clement Verna wrote:
>On Thu, 3 Dec 2020 at 16:21, Pierre-Yves Chibon <[1]pin...@pingoured.fr>
>wrote:
> 
>  On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
>  > On Thu, Dec 3, 2020 at 4:03 PM Ben Cotton <[2]bcot...@redhat.com>
>  wrote:
>  > >
>  > > [3]https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>  > >
>  > > == Summary ==
>  > >
>  > > This Change will move Fedora git repositories to use "main" as the
>  > > default git branch instead of "master". Specific repositories will
>  be
>  > > manually moved and default git branch for new projects will be set
>  to
>  > > use "main".
>  >
>  > Is there a reason why "main" is proposed instead of "rawhide" on
>  src.fp.o?
>  > For all non-dist-git repositories I am fine with "main", but if we are
>  > changing this anyway, "rawhide" would actually make more sense for
>  > dist-git repos.
> 
>  One of the argument was that not every namespace on dist-git has a
>  rawhide
>  version, for example containers do not have/use rawhide.
> 
>There is a fedora:rawhide base image container and I think most dockerfile
>from the master branch are using this image for their base. So calling the
>master branch rawhide would be ok for containers :-)

After looking at the infra and releng issue trackers Kevin managed to found back
the ticket I was thinking about.
You have my apologies, the namespace that was asking to a different default
branch and for that branch to not be named "rawhide" was flatpaks.
They wanted the default branch to be "stable", which would not apply to most
other namespaces. Thus the proposal to go with "main" which works for all
namespaces and seems to be on its way to become the industry standard.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 34 Change: GitRepos-master-to-main (Self-Contained Change)

[Pierre-Yves Chibon]

On Thu, Dec 03, 2020 at 04:39:35PM +0100, Petr Šabata wrote:
> On Thu, Dec 3, 2020 at 4:34 PM Pierre-Yves Chibon  wrote:
> >
> > On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote:
> > > Since I don't see those on the list, does this impact
> > >
> > > * rpkg (fedpkg)?
> >
> > Wrapper to git, should not be impacted. The only thing I could think of was:
> > when we fedpkg clone an empty git repo, have fedpkg do the "git branch -M 
> > main"
> > directly. That being said, I'm not 100% sure when we creating a project on
> > dist-git today we create them empty.
> 
> Also fedpkg anything that tries to figure out what the release string
> and build target are based on the branch name. E.g. fedpkg build.

Good point

> > > * koji (if no git commit is provided)?
> >
> > koji builds from a git reference be that a commit, branch name or git tag.
> > There will be no consequences for koji there (instead of building from
> > url#master you'll be build from url#main).
> 
> Yes, but I think, and correct me if I'm wrong, that if the SCMURL is
> simply a repo name, it uses master HEAD. You could say it's an edge
> case but if it does that, is should now attempt to use main, with
> master as a fallback.

It then uses HEAD which would be the same thing as what you get when you git
clone a repo and with this change it'll point to main.

Something to test/confirm, but I'm really pretty sure that it'll be fine.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 34 Change: GitRepos-master-to-main (Self-Contained Change)

[Pierre-Yves Chibon]

On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote:
> Since I don't see those on the list, does this impact
> 
> * rpkg (fedpkg)?

Wrapper to git, should not be impacted. The only thing I could think of was:
when we fedpkg clone an empty git repo, have fedpkg do the "git branch -M main"
directly. That being said, I'm not 100% sure when we creating a project on
dist-git today we create them empty.

> * koji (if no git commit is provided)?

koji builds from a git reference be that a commit, branch name or git tag.
There will be no consequences for koji there (instead of building from
url#master you'll be build from url#main).

> * COPR?

I'll let the COPR folks answer.

> * Koschei or other such services?

I don't know enough koschei to answer for it.
For the other services, we've tried to be exhaustive. If you can think of some
we missed/may have missed feel free to raise them.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 34 Change: GitRepos-master-to-main (Self-Contained Change)

[Pierre-Yves Chibon]

On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
> On Thu, Dec 3, 2020 at 4:03 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> >
> > == Summary ==
> >
> > This Change will move Fedora git repositories to use "main" as the
> > default git branch instead of "master". Specific repositories will be
> > manually moved and default git branch for new projects will be set to
> > use "main".
> 
> Is there a reason why "main" is proposed instead of "rawhide" on src.fp.o?
> For all non-dist-git repositories I am fine with "main", but if we are
> changing this anyway, "rawhide" would actually make more sense for
> dist-git repos.

One of the argument was that not every namespace on dist-git has a rawhide
version, for example containers do not have/use rawhide.
And having different default branches on different namespaces is not very
appealing.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: GitLab AMA Topic Follow Up: Namespace & Issue Tracking

[Pierre-Yves Chibon]

On Mon, Nov 23, 2020 at 10:22:25AM +, Aoife Moloney wrote:
> # GitLab AMA Session Topic - Namespace & Issue Tracking
> 
> Hi everyone,
> 
> Thanks again for your involvement in the GitLab AMA session on IRC in
> September. This email discussion thread is on Namespace & Issue
> Tracking. I have pulled the relevant questions and answers from the
> original hackmd doc into one email and if you would like to discuss
> this topic specifically, here might be a good place to do so so your
> conversations don't go down a 'rabbit hole' :)
> 
> Here are some links to resources as well:
> * Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
> * Chat log from session
> https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html
> * AMA Blog post
> https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
> * Here is this email in hackmd if you wish to view it there:
> https://hackmd.io/oZrDwbSeSWO-l_X65A1ndg?view
> 
> ## Namespace & Issue Tracking
> - Question: Currently dist-git in Fedora has several namespaces: rpms,
> modules, containers, tests... All namespaces but the ``tests``
> namespace have their issue tracker in bugzilla. Would this work in
> gitlab? Can we selectively enable/disable issue tracking per namespace
> for the entire instance? (ie: w/o giving the possibility to ``owner``
> or ``maintainer`` to toggle that setting.)
> - Answer: It may need to be checked again, but it appears you can
> turn on/off the issue tracker at the project level.

Which would be fine since only infra and releng would be admins, so "regular"
packager could not turn this feature back on.

> - Question: Currently dist-git in Fedora has several namespaces: rpms,
> modules, containers, tests... All namespaces but the ``tests``
> namespace have their issue tracker in bugzilla. Would this work in
> gitlab? Can we selectively enable/disable issue tracking per namespace
> for the entire instance? (ie: w/o giving the possibility to ``owner``
> or ``maintainer`` to toggle that setting.)
> - Answer: You can turn the GitLab issue tracker on and off by
> project. See 
> https://docs.gitlab.com/ee/user/project/settings/#sharing-and-permissions
> Namespaces map to “group” in GitLab. Here’s more info about them:
> https://docs.gitlab.com/ee/api/namespaces.html

Looks like a duplicated question, but the answer is the same :)

> - Question: Fedora, as far as I understand, still plan on using
> bugzilla as issue tracker. Currently default assignee and the CC are
> gathered using the ``main admin`` (ie: the ``owner`` for GitLab iiuc),
> the other maintainers (who did not ``unwatch issues`` in the project -
> mechanism for them to opt-out of being in the CC list) and the people
> having enabled ``Issue watching`` for the project (mechanism for them
> to opt-in into being in the CC list). Would this work in a GitLab
> world?
> - Answer: There are a number of options related to that.  For one,
> users can control their notifications globally and by name space in a
> fine grained way (see GitLab Notification Emails).

This is not actually answering the question.
We need two information for every project/package:
- a default assignee (a single person)
- a list of people to add on Cc

Currently it is:
- default assignee == main admin
- Cc list ==
  - all packagers with commit access and above who have not "unwatch" the
project (which is the mechanism allowing packager with commits to not be
included in the Cc list, this is used among others by the kernel folks)
  - everyone who "watches issues" on a package (even if they are not packagers).

From one of the previous threads, I believe the solution thought for this was
basically: pkgdb3 
It would be our central system to integrate gitlab with every other application
that is package related in Fedora (anitya, bugzilla, new package requests, new
branch requests, ACL requests).
pkgdb2 was a glorified gitolite admin UI, pkgdb3 would be a glorified gitlab
admin UI :)


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Weekly: 2020-11-22

[Pierre-Yves Chibon]

On Tue, Nov 24, 2020 at 06:30:10AM -, Tom Seewald wrote:
> > On Mon, 23 Nov 2020 at 05:54, Aoife Moloney  > wrote:
> > 
> > What is OSBS? Please don't use undefined acronyms.
> 
> OSBS = OpenShift Build Service

It's the tool we use to build containers in our infrastructure (and thus also
flatpaks)


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Summary/Minutes from today's FESCo Meeting (2020-11-11)

[Pierre-Yves Chibon]

On Fri, Nov 13, 2020 at 10:11:28AM +0100, Petr Pisar wrote:
> On Fri, Nov 13, 2020 at 09:58:22AM +0100, Pierre-Yves Chibon wrote:
> > On Fri, Nov 13, 2020 at 12:52:06AM +0100, Kevin Kofler via devel wrote:
> > > Matthew Miller wrote:
> > > > Well, except, it clearly *does* work that way. We have many
> > > > lightly-maintained packages in practice.
> > > 
> > > Do we really? Which are those packages?
> > 
> > Every single package that failed to build from source and that people 
> > refused to
> > see orphaned and retired when it was pointed out that they are in fact not
> > really maintained ?
> > 
> Those packages are automatically removed from Rawhide. Aren't they?

Now, yes (irc).


Pierre


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

Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)

[Pierre-Yves Chibon]

On Fri, Nov 13, 2020 at 12:52:06AM +0100, Kevin Kofler via devel wrote:
> Matthew Miller wrote:
> > Well, except, it clearly *does* work that way. We have many
> > lightly-maintained packages in practice.
> 
> Do we really? Which are those packages?

Every single package that failed to build from source and that people refused to
see orphaned and retired when it was pointed out that they are in fact not
really maintained ?


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Self Introduction: Davide Cavalca

[Pierre-Yves Chibon]

On Thu, Oct 29, 2020 at 11:52:09AM -0700, Michel Alexandre Salim wrote:
> On Thu, 2020-10-29 at 13:12 +0100, Vít Ondruch wrote:
> >  
> > This might be a good time to start discussing the possibility of
> > having
> > "organization" ACLs (e.g. if a bunch of employees at FB, or Datto, or
> > another company -- or, say, an Apache project want to collectively
> > maintain packages).
> >   
> > Are you proposing "pkgdb" group such as:
> >  
> > https://admin.fedoraproject.org/accounts/group/view/ruby-packagers-sig
> >  
> > https://admin.fedoraproject.org/accounts/group/view/nodejs-sig
> >  
> > https://admin.fedoraproject.org/accounts/group/view/virtmaint-sig
> >  
> Yes, precisely. Just with a slightly different scope.
> >  
> > But groups can't be the "main admin" of a package.
> >  
> That part is fine, the pkgdb group is sufficient to make sure a
> consistent set of maintainers have access to the packages.
> 
> If there's no philosophical objection I can open an infra ticket and
> see where it goes.

If you open a ticket, this may be an useful read prior to doing so:
https://pagure.io/fedora-infra/howtos/blob/master/f/groups_in_fedora.md?text=True

(It'll help providing all the infos needed in the ticket).


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Mass spec change: Replace Python 3 version globs (3.?) with macros to support 3.10

[Pierre-Yves Chibon]

On Thu, Oct 29, 2020 at 02:05:53PM -, Tomas Hrnciar wrote:
> Hello everyone,
> 
> I am just letting you know that we successfully replaced all 3.? globs 
> yesterday.

Thanks! Both for doing it and the heads-up :)


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: GitLab AMA Topic Discussion: Permissions & Access

[Pierre-Yves Chibon]

On Wed, Oct 28, 2020 at 09:56:11AM -0400, Neal Gompa wrote:
> On Wed, Oct 28, 2020 at 8:57 AM Pierre-Yves Chibon  
> wrote:
> >
> > On Sun, Oct 25, 2020 at 09:17:04PM +, Aoife Moloney wrote:
> > > Hi everyone,
> > >
> > > Thanks again for your involvement in the GitLab AMA session on IRC in
> > > September. As promised, this is the first of a 5-part series breaking
> > > down main topics that came up during the session. I will send a topic
> > > every week for discussion to both Fedora and CentOS devel lists. I
> > > have pulled the relevant questions and answers from the original
> > > hackmd doc into one email. If you would like to discuss this topic
> > > specifically, here might be a good place to do so. I dont consider
> > > myself technical enough to weigh in on details, but I am happy to
> > > facilitate as best I can via email. And more importantly (for me),
> > > learn from the discussion too.
> > >
> > > Here are some links to resources as well:
> > > * Questions and Answers hackmd link 
> > > https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
> > > * Chat log from session
> > > https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html
> > > * AMA Blog post
> > > https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
> > > * Here is this email in hackmd if you wish to view it there:
> > > https://hackmd.io/1pjX1cVnTjekOLVowj5UiQ?view
> > >
> > > ## Topic: Permission and Access
> > >
> > > - Question: Fedora has a group-based access system. People in the
> > > `packager` group have (commit) access to only the packages they
> > > maintain. People in the `provenpackager` group have (commit) access to
> > > all the active packages, but a few (for legal reason). People in the
> > > `releng` group have commit access to all the packages. Is this an
> > > access model that GitLab can support? If not, how would this work in a
> > > GitLab world? How would notifications work (Esp consider people in the
> > > `provenpackager` or `releng` group do not want to be notified for all
> > > the projects they have access to)?
> > > - Answer: What I explored was something along the lines of :
> > > - Packager → Using GitLab’s Maintainer or Developer role for
> > > the project they maintain (Maintainer have the ability to access
> > > project settings and change pretty much everything there, so that
> > > might be blocking here, Developer only have commit access, so we need
> > > another way to change some settings for Packagers)
> >
> > Considering the amount of settings we do not want packagers to change
> > (no-force-push, no-deletion, no FXX branch creation...), I agree that giving
> > maintainer access is likely not going to work for us and therefore it'll 
> > have to
> > be 'developer' access.
> >
> > > - Co-Maintainer → Using GitLab’s Developer role (commit access)
> > > - Proven-Packager → GitLab’s Developer role on all repo (expect 2)
> > > - Release Engineer/Admin/etc .. → GitLab’s Owner role on all repos
> > > - This is not an exact matching with what we currently have
> > > but should give us a way to experiment with this and look at what is
> > > acceptable or not.
> > > - There is also a GitLab ticket
> > > (https://gitlab.com/gitlab-org/gitlab/-/issues/7626) to implement
> > > policies for the project that could give more granular control of
> > > permissions.
> >
> > So if this gets implemented, we would be able to pick and choose which 
> > settings
> > are available to developer and which are available to admins only, is that
> > correct?
> >
> 
> Maybe. I've been burned by GitLab scoping out all the actual things me
> and others ask for and building features that nobody wants and doesn't
> do enough. The Epic that replaced that issue
> (https://gitlab.com/groups/gitlab-org/-/epics/4168) seems to indicate
> that the implementation will mainly offer label and archive control
> and not much else.

So if this ticket/epic does not get us what we want, we'll need a proxy service
to add/remove users/groups to a project?
 
> > > - Question: Fedora supports the concept of a retired `project` (ie:
> > > archived) that no-one can commit to. Does GitLab have an equivalent
> > > concept? (The retired status is not something project admins can
> > > change)
> > > - Answer: There is an opt

Re: GitLab AMA Topic Discussion: Permissions & Access

[Pierre-Yves Chibon]

On Sun, Oct 25, 2020 at 09:17:04PM +, Aoife Moloney wrote:
> Hi everyone,
> 
> Thanks again for your involvement in the GitLab AMA session on IRC in
> September. As promised, this is the first of a 5-part series breaking
> down main topics that came up during the session. I will send a topic
> every week for discussion to both Fedora and CentOS devel lists. I
> have pulled the relevant questions and answers from the original
> hackmd doc into one email. If you would like to discuss this topic
> specifically, here might be a good place to do so. I dont consider
> myself technical enough to weigh in on details, but I am happy to
> facilitate as best I can via email. And more importantly (for me),
> learn from the discussion too.
> 
> Here are some links to resources as well:
> * Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
> * Chat log from session
> https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html
> * AMA Blog post
> https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
> * Here is this email in hackmd if you wish to view it there:
> https://hackmd.io/1pjX1cVnTjekOLVowj5UiQ?view
> 
> ## Topic: Permission and Access
> 
> - Question: Fedora has a group-based access system. People in the
> `packager` group have (commit) access to only the packages they
> maintain. People in the `provenpackager` group have (commit) access to
> all the active packages, but a few (for legal reason). People in the
> `releng` group have commit access to all the packages. Is this an
> access model that GitLab can support? If not, how would this work in a
> GitLab world? How would notifications work (Esp consider people in the
> `provenpackager` or `releng` group do not want to be notified for all
> the projects they have access to)?
> - Answer: What I explored was something along the lines of :
> - Packager → Using GitLab’s Maintainer or Developer role for
> the project they maintain (Maintainer have the ability to access
> project settings and change pretty much everything there, so that
> might be blocking here, Developer only have commit access, so we need
> another way to change some settings for Packagers)

Considering the amount of settings we do not want packagers to change
(no-force-push, no-deletion, no FXX branch creation...), I agree that giving
maintainer access is likely not going to work for us and therefore it'll have to
be 'developer' access.

> - Co-Maintainer → Using GitLab’s Developer role (commit access)
> - Proven-Packager → GitLab’s Developer role on all repo (expect 2)
> - Release Engineer/Admin/etc .. → GitLab’s Owner role on all repos
> - This is not an exact matching with what we currently have
> but should give us a way to experiment with this and look at what is
> acceptable or not.
> - There is also a GitLab ticket
> (https://gitlab.com/gitlab-org/gitlab/-/issues/7626) to implement
> policies for the project that could give more granular control of
> permissions.

So if this gets implemented, we would be able to pick and choose which settings
are available to developer and which are available to admins only, is that
correct?

What about the default point of contact. We need one packager to be the default
point of contact in bugzilla for every project/package. Currently we assume the
main-admin is that point of contact unless told otherwise via the bugzilla
overrides.
How would this work in a gitlab model if all the maintainers are at developer
level?
 
> - Question: Fedora supports the concept of a retired `project` (ie:
> archived) that no-one can commit to. Does GitLab have an equivalent
> concept? (The retired status is not something project admins can
> change)
> - Answer: There is an option to have a “retired” group which is
> configured to have nobody with commit access. Then retiring a project
> would simply mean to move the project from the “rpm” group to
> “retired” group for example.
> There is also possibility to simply archive projects
> https://docs.gitlab.com/ee/user/project/settings/#archiving-a-project

Does that mean that the URL of the project will change? (or are there redirects
that are automatically created?)
What if rpms/cockpit and container/cockpit both get retired? Can we do
retired/rpms/cockpit and retired/container/cockpit? Or should we do
retired/rpms_cockpit and retired/container_cockpit?

I figure only admins can move project between groups or archive/unarchive
projects. That means we'll need a way for packagers to indicate their wish to
retire a project and then a bot to actually do it.

> - Question: could gitlab (inc) maintain a Community Edition GitLab
> instance that Fedora uses?
> - Answer: There is no plan to create custom versions of GitLab for
> customers. Instead, GitLab encourages paid customers and free users
> alike to contribute upstream to make sure that GitLab continues to
> work well 

Re: Unresponsive packagers: wolnei and dturecek

[Pierre-Yves Chibon]

On Sat, Oct 10, 2020 at 09:08:29AM +0200, Pierre-Yves Chibon wrote:
> On Fri, Oct 09, 2020 at 09:53:58PM +0200, Pavel Raiskup wrote:
> > On Friday, October 9, 2020 4:59:32 PM CEST Pierre-Yves Chibon wrote:
> > > - dturecek has no corresponding bugzilla account - First notification Oct 
> > > 1st
> > 
> > Dominik left Red Hat ~10 days ago, so he probably lost the access to his
> > FAS account.  I informed him on his personal email.
> 
> The address in FAS is not a @redhat.com one.
> Thanks for reaching out though, I hope your email reaches him with more 
> success
> than our notifications :)

It looks like Dominik's situation is fixed.

We only have wolnei and Sergio (who reached out to the list a few days ago) now.

Does anyone know how to contact wolnei?


Thanks,
Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Unresponsive packagers: wolnei and dturecek

[Pierre-Yves Chibon]

On Fri, Oct 09, 2020 at 09:53:58PM +0200, Pavel Raiskup wrote:
> On Friday, October 9, 2020 4:59:32 PM CEST Pierre-Yves Chibon wrote:
> > - dturecek has no corresponding bugzilla account - First notification Oct 
> > 1st
> 
> Dominik left Red Hat ~10 days ago, so he probably lost the access to his
> FAS account.  I informed him on his personal email.

The address in FAS is not a @redhat.com one.
Thanks for reaching out though, I hope your email reaches him with more success
than our notifications :)


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

Unresponsive packagers: wolnei and dturecek

[Pierre-Yves Chibon]

Good Morning Everyone,

The following two accounts do not have a valid bugzilla account associated with
their email in FAS.
They have received a daily notification about it (and thus so have we) and so
far in vain.

- wolnei has no corresponding bugzilla account - First notification Sept 29th
wolnei is main admin of rpms/kio-gdrive
wolnei has a bugzilla override on rpms/kio-gdrive


- dturecek has no corresponding bugzilla account - First notification Oct 1st
dturecek is maintainer of rpms/copr-backend
dturecek is maintainer of rpms/copr-cli
dturecek is maintainer of rpms/copr-dist-git
dturecek is maintainer of rpms/copr-frontend
dturecek is maintainer of rpms/copr-keygen
dturecek is maintainer of rpms/copr-rpmbuild
dturecek is maintainer of rpms/copr-selinux
dturecek is maintainer of rpms/python-copr
dturecek is main admin of rpms/python-copr-common


Does anyone know how to contact them?

Thanks in advance for your help,
Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: EPEL8 Branch Request: perl-Data-GUID

[Pierre-Yves Chibon]

On Thu, Oct 08, 2020 at 03:27:22PM +0200, Pierre-Yves Chibon wrote:
> On Thu, Oct 08, 2020 at 03:22:46PM +0200, Emmanuel Seyman wrote:
> > 
> > Hello, all.
> > 
> > Ralf Corsepius has requested that someone give Paul Howarth and Jitka
> > Plesnikova collaborator rights in bug #1870755 . Their FAS usernames
> > are pghmcfc and jplesnik respectively.
> > 
> > Is there someone on the list who can do this?
> 
> I can, on it.

Done


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: EPEL8 Branch Request: perl-Data-GUID

[Pierre-Yves Chibon]

On Thu, Oct 08, 2020 at 03:22:46PM +0200, Emmanuel Seyman wrote:
> 
> Hello, all.
> 
> Ralf Corsepius has requested that someone give Paul Howarth and Jitka
> Plesnikova collaborator rights in bug #1870755 . Their FAS usernames
> are pghmcfc and jplesnik respectively.
> 
> Is there someone on the list who can do this?

I can, on it.

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Unresponsive packagers: ekulik, imcleod and lsun

[Pierre-Yves Chibon]

On Sat, Oct 03, 2020 at 04:04:46AM -, Liming Sun wrote:
> Apology for the late reply. I had email issues from upstream community 
> recently. Somehow my Redhat Bugzilla account seems not accessible anymore 
> either. I recreated the account with the same email address 
> (l...@mellanox.com). Is this what's needed for this issue? 


Yes, you are all clear on my side, thanks for getting back to us!


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